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, пакуль памылка не знікне, можа пакінуць наступны звычайны перазапуск з той самай праблемай.