Squid shm_open: ההרשאה נדחתה — בדקו את הבעלות על הזיכרון המשותף

Could not read pid file ו-shm_open(...): Permission denied עשויים להופיע באותו אתחול כושל של Squid. הם מציינים משאבים שונים. תיקון הבעלות של תיקיית מטמון אינו מתקן, כשלעצמו, אף אחד מהם.

ב-Linux, אובייקט זיכרון משותף של POSIX מיוצג בדרך כלל תחת /dev/shm. הבעלים ומצב הגישה שלו חשובים. לכן אובייקט שהושאר על ידי זהות הרצה אחרת עלול לגרום לכשל בתהליך מאוחר יותר, גם כאשר squid.conf קריא והפורט המאזין פנוי.

שחזרו כיצד המופע הזה הופעל

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

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

עבור כל משאב, השוו את גישת ההרצה הנדרשת לבעלים ולמצב הנוכחיים שלו. אם ההרשאות הרגילות נראות מספיקות, בחנו את ראיות הדחייה הרלוונטיות ב-SELinux או ב-AppArmor. “Permission denied” לבדו אינו מזהה איזו שכבה דחתה את הגישה.

תקנו את הבעלות בלי ליצור בעיה שנייה

שמרו על חשבון ההרצה בהתאם לתצורת השירות של ההתקנה. העברת הכול ל-nobody עלולה לשבור גישת עזר ולהכניס אי-התאמה חדשה עם קבצים המנוהלים על ידי השירות.

גם מחיקת כל אובייקט דמוי Squid ב-/dev/shm אינה צעד ראשון טוב. אובייקט בעל שם עשוי להשתייך למופע פעיל. ניקוי, כשנדרש, צריך לכוון למשאב נטוש מאומת כשהשירות המושפע עצור, ואחריו הפעלה דרך מנגנון השירות הרגיל.

התוצאה המועילה היא מודל הפעלה ובעלות עקבי. הרצת פקודה אחת כ-root עד שהשגיאה תיעלם עלולה להשאיר את האתחול השגרתי הבא עם בדיוק אותה בעיה.