Squid shm_open: přístup odepřen — zkontrolujte vlastnictví sdílené paměti
Odlište selhání vlastnictví sdílené paměti Squidu od chyb oprávnění PID, logu a adresáře mezipaměti.
Could not read pid file a shm_open(...): Permission denied se mohou objevit při stejném neúspěšném startu Squidu. Označují různé prostředky. Oprava vlastnictví adresáře mezipaměti sama o sobě neopraví ani jedno z nich.
V Linuxu je objekt sdílené paměti POSIX obvykle zastoupen pod /dev/shm. Záleží na jeho vlastníkovi a režimu přístupu. Objekt ponechaný jinou identitou běhu proto může způsobit selhání pozdějšího procesu, i když je squid.conf čitelný a naslouchající port je volný.
Rekonstruujte, jak byla tato instance spuštěna
Porovnejte běžné spuštění služby s jakýmkoli ručním spuštěním použitým při řešení potíží. Ručně spuštěný proces a zabalená služba mohou používat různé uživatele, cesty nebo konfigurační soubory. Než objekt označíte za zastaralý, zjistěte, zda stále běží jiná instance Squidu.
Poté si přečtěte přesnou selhávající operaci. Chyba PID se týká nakonfigurovaného umístění PID a jeho nadřazeného adresáře. Chyba logu se týká logovacího souboru nebo adresáře. Chyba inicializace mezipaměti se týká úložiště. Chyba shm_open se týká pojmenovaného objektu sdílené paměti a může zahrnovat i bezpečnostní politiku uplatňovanou na proces.
U každého prostředku porovnejte požadovaný přístup za běhu s jeho současným vlastníkem a režimem. Pokud se běžná oprávnění zdají dostatečná, prohlédněte příslušné důkazy odmítnutí v SELinuxu nebo AppArmoru. Samotné “Permission denied” neukazuje, která vrstva přístup odmítla.
Opravte vlastnictví, aniž byste vytvořili druhý problém
Udržujte účet běhu v souladu s konfigurací služby instalace. Přepnutí všeho na nobody může narušit přístup pomocných nástrojů a zavést nový nesoulad se soubory spravovanými službou.
Smazat každý objekt připomínající Squid v /dev/shm také není dobrý první krok. Pojmenovaný objekt může patřit aktivní instanci. Úklid, je-li nutný, má cílit na potvrzený opuštěný prostředek se zastavenou postiženou službou a poté následovat spuštění běžným mechanismem služby.
Užitečným výsledkem je konzistentní model spouštění a vlastnictví. Spouštění jednoho příkazu jako root, dokud chyba nezmizí, může ponechat příští rutinní restart s přesně stejným problémem.