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 до исчезновения ошибки может оставить следующую плановую перезагрузку ровно с той же проблемой.