מחיקת מטמון NGINX מציבה שגיאות ביטול קישור קריטיות ביומן השגיאות

פורסם: 15 בפברואר 2025 בשעה 11:25:19 UTC

מאמר זה מסביר כיצד למחוק פריטים מהמטמון של NGINX מבלי שקובצי היומן שלך יהיו עמוסים בהודעות שגיאה. למרות שאינה גישה מומלצת בדרך כלל, היא עשויה להיות שימושית במקרים מסוימים של קצה.

עמוד זה תורגם במכונה מאנגלית על מנת להנגיש אותו לכמה שיותר אנשים. למרבה הצער, תרגום מכונה עדיין אינו טכנולוגיה משוכללת, ולכן עלולות להתרחש שגיאות. אם אתה מעדיף, תוכל לצפות בגרסה האנגלית המקורית כאן:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

המידע בפוסט זה מבוסס על מטמון FastCGI ב-NGINX 1.4.6 הפועל ב-Ubuntu Server 14.04 x64. זה עשוי להיות תקף עבור גרסאות אחרות או לא.

(עדכון 2025: בזמן שבין כתבתי את הפוסט המקורי לעכשיו, הרבה השתנה. השרתים מהירים יותר וזולים יותר, כך שלמעשה לא הייתי ממליץ על הגישה המתוארת בפוסט הזה, שבה אני מנסה לנהל במיקרו את תפוגת המטמון רק כדי לשמור כמה דורות נוספים של תוכן דינמי. אשאיר את התוכן כאן לעיון עתידי ובמקרה שמישהו באמת צריך את זה מכל סיבה נוכחית זו עדיין לא עובדת מסיבה נוכחית זו עדיין לא עובדת מסיבה נוכחית X. אמנם, אבל אני חושב שכן).

לאחר העברה של מספר אתרים מ-Apache ל-NGINX, אהבתי מאוד את יכולות המטמון המובנות שלו, שעובדות טוב מאוד ברוב הנסיבות מבלי להתערב ממני.

עם זאת, עבור אחד האתרים, באמת הייתי צריך את היכולת לנקות את המטמון (גם במלואו וגם להסיר ערכים בודדים) בעצמי. מהדורת הקהילה החינמית של NGINX תומכת רק בתפוגת מטמון מבוסס-זמן (כלומר אתה יכול להגדיר אותו כדי לבדוק אם משהו השתנה לאחר שעה, יום וכו'). אבל מה אם אין דרך אמינה לקבוע מבעוד מועד מתי ישתנה משאב מסוים? למשל, אין לי מושג אם יעבור שעה, יום או שנה עד שאחזור ואערוך משהו בפוסט הזה – ולמה מטמון רק לשעה אם שמירה במטמון ליום אחד היה בסדר?

זה המקום שבו יש צורך ביכולת לנקות את המטמון באופן ידני (או על ידי יישום האינטרנט שלך להודיע ל-NGINX שיש לטהר משהו). האנשים שמאחורי NGINX מודעים בבירור לצורך בכך מכיוון שהתכונה נתמכת בגרסה בתשלום של המוצר שלהם - אבל למרות שהם בהחלט זכאים להגדיר את הרישוי שלהם בכל דרך שהם רוצים, המחיר קצת תלול עבורי כאשר הפונקציה הזו היא התכונה בתשלום היחידה שאני באמת צריך.

למרבה המזל, מסתבר שאתה יכול פשוט למחוק קבצים מספריית המטמון בעצמך ו-NGINX יקלוט את זה ותביא עותק חדש מהחלק האחורי שלך ללא תקלות. עם זאת, אם תעשה זאת מבלי לשנות את התצורה שלך, סביר להניח שתראה חבורה שלמה של הודעות דומות לזו ביומן השגיאות שלך לאחר זמן מה:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

נראה ששגיאות אלו מתרחשות כאשר NGINX עצמו מנסה למחוק ערכי מטמון לאחר הזמן שצוין על ידי הפרמטר הלא פעיל של הוראת fastcgi_cache_path . ברירת המחדל עבור זה היא רק 10 דקות, אבל אתה יכול להגדיר אותו לכל ערך שאתה רוצה. אם תגדיר אותו ל-, נניח, 10 שנים, סביר להניח שלא הפעלת מחדש את השרת בינתיים, כך שאינדקס המפתח בזיכרון היה מתנקה בינתיים. אם תעשה זאת, האם עליך לוודא שאתה מנקה את המטמון בעצמך, NGINX לא יעשה זאת יותר עבורך.

אני מוצא שזה ממש מוזר שזה נחשב שגיאה קריטית שלא ניתן למחוק ערך מטמון כי הוא לא קיים. העובדה שסיווג החומרה שלו כל כך גבוה פירושה שאי אפשר להיפטר ממנו רק על ידי התעלמות מכניסות יומן מתחת לסף מסוים. ברגע שיובא עותק חדש מהחלק האחורי הערך יתקיים שוב, אז זו צריכה להיות אזהרה לכל היותר, לדעתי.

כעת, אם לא ניתן היה למחוק את ערך המטמון בגלל בעיות עם הרשאות או משהו שלישי, זו תהיה שגיאה קריטית, מכיוון שהיא עלולה לגרום ל-NGINX להמשיך להגיש תוכן שמור הרבה אחרי זמן התפוגה שלו, אבל נראה שתהליך הניקוי לא עושה את ההבחנה הזו.