Squid shm_open: prístup zamietnutý — skontrolujte vlastníctvo zdieľanej pamäte

Could not read pid file a shm_open(...): Permission denied sa môžu objaviť pri tom istom neúspešnom štarte Squidu. Označujú rôzne prostriedky. Oprava vlastníctva adresára vyrovnávacej pamäte sama o sebe neopraví ani jedno z nich.

V Linuxe je objekt zdieľanej pamäte POSIX zvyčajne zastúpený pod /dev/shm. Záleží na jeho vlastníkovi a režime prístupu. Objekt ponechaný inou identitou behu preto môže spôsobiť zlyhanie neskoršieho procesu, aj keď je squid.conf čitateľný a počúvajúci port je voľný.

Zrekonštruujte, ako bola táto inštancia spustená

Porovnajte bežné spustenie služby s akýmkoľvek ručným spustením použitým pri riešení problému. Ručne spustený proces a zabalená služba môžu používať rôznych používateľov, cesty alebo konfiguračné súbory. Zistite, či ešte beží iná inštancia Squidu, skôr než objekt označíte za zastaraný.

Potom si prečítajte presnú zlyhávajúcu operáciu. Chyba PID sa týka nakonfigurovaného umiestnenia PID a jeho nadradeného adresára. Chyba logu sa týka logovacieho súboru alebo adresára. Chyba inicializácie vyrovnávacej pamäte sa týka úložiska. Chyba shm_open sa týka pomenovaného objektu zdieľanej pamäte a môže zahŕňať aj bezpečnostnú politiku uplatňovanú na proces.

Pri každom prostriedku porovnajte požadovaný prístup pri behu s jeho súčasným vlastníkom a režimom. Ak sa bežné oprávnenia zdajú dostatočné, preskúmajte príslušné dôkazy odmietnutia v SELinuxe alebo AppArmore. Samotné “Permission denied” neukazuje, ktorá vrstva prístup odmietla.

Opravte vlastníctvo bez vytvorenia druhého problému

Udržujte účet behu v súlade s konfiguráciou služby inštalácie. Prepnutie všetkého na nobody môže narušiť prístup pomocných nástrojov a zaviesť nový nesúlad so súbormi spravovanými službou.

Zmazanie každého objektu pripomínajúceho Squid v /dev/shm tiež nie je dobrý prvý krok. Pomenovaný objekt môže patriť aktívnej inštancii. Čistenie, ak je potrebné, má cieliť na potvrdený opustený prostriedok so zastavenou postihnutou službou a potom nasledovať spustenie bežným mechanizmom služby.

Užitočným výsledkom je konzistentný model spúšťania a vlastníctva. Spúšťanie jedného príkazu ako root, kým chyba nezmizne, môže ponechať nasledujúci rutinný reštart s presne tým istým problémom.