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 ليس خطوة أولى جيدة. فقد ينتمي كائن مسمّى إلى مثيل نشط. والتنظيف، حيث يلزم، ينبغي أن يستهدف موردًا مهجورًا مؤكدًا مع إيقاف الخدمة المتأثرة، ثم بدء التشغيل عبر آلية الخدمة العادية.

النتيجة المفيدة هي نموذج إطلاق وملكية متسق. فتشغيل أمر واحد بصلاحية الجذر حتى يختفي الخطأ قد يترك إعادة التشغيل الروتينية التالية مع المشكلة نفسها تمامًا.