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