Squid shm_open: доступ заборонено — перевірте власника спільної пам'яті
Відокремте збої власника спільної пам'яті Squid від помилок прав доступу до PID, журналу та каталогу кешу.
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, доки помилка не зникне, може залишити наступний плановий перезапуск саме з тією самою проблемою.