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 не е добар прв чекор. Именуван објект може да припаѓа на активна инстанца. Чистењето, кога е потребно, треба да биде насочено кон потврден напуштен ресурс со запрена засегната услуга, по што следи стартување преку нормалниот механизам на услугата.

Корисниот резултат е доследен модел на стартување и сопственост. Извршувањето на една команда како root додека грешката не исчезне може да го остави следното рутинско рестартирање со токму истиот проблем.