Squid shm_open: hozzáférés megtagadva — ellenőrizze a megosztott memória tulajdonjogát
Válassza szét a Squid megosztott memóriájának tulajdonjogi hibáit a PID-, napló- és gyorsítótár-könyvtár engedélyhibáitól.
Could not read pid file és shm_open(...): Permission denied ugyanazon sikertelen Squid-indítás során is megjelenhet. Különböző erőforrásokat neveznek meg. Egy gyorsítótár-könyvtár tulajdonjogának javítása önmagában egyiket sem javítja.
Linuxon a POSIX megosztott memória objektum általában a /dev/shm alatt jelenik meg. A tulajdonos és a hozzáférési mód számít. Ezért egy másik futásidejű identitás által hátrahagyott objektum miatt egy későbbi folyamat meghiúsulhat, akkor is, ha a squid.conf olvasható, és a figyelő port szabad.
Rekonstruálja, hogyan indult el ez a példány
Hasonlítsa össze a szolgáltatás szokásos indítását a hibakeresés során használt bármely kézi indítással. A kézzel indított folyamat és a csomagolt szolgáltatás eltérő felhasználókat, útvonalakat vagy konfigurációs fájlokat használhat. Állapítsa meg, fut-e még másik Squid-példány, mielőtt egy objektumot elavultnak tekint.
Ezután olvassa el a pontos hibás műveletet. A PID-hiba a beállított PID-helyre és annak szülőkönyvtárára vonatkozik. A naplóhiba a naplófájlra vagy a könyvtárra vonatkozik. A gyorsítótár inicializálási hibája a tárolóra vonatkozik. A shm_open hiba a megnevezett megosztott memória objektumra vonatkozik, és magában foglalhatja a folyamatra alkalmazott biztonsági szabályzatot is.
Minden erőforrásnál hasonlítsa össze a szükséges futásidejű hozzáférést a jelenlegi tulajdonossal és móddal. Ha a szokásos engedélyek elegendőnek tűnnek, vizsgálja meg a vonatkozó SELinux- vagy AppArmor-elutasítási bizonyítékokat. A „Permission denied” önmagában nem azonosítja, melyik réteg tagadta meg a hozzáférést.
Javítsa a tulajdonjogot anélkül, hogy második problémát okozna
Tartsa a futásidejű fiókot összhangban a telepítés szolgáltatáskonfigurációjával. Ha mindent a nobody fiókra vált, az megtörheti a segédprogramok hozzáférését, és új eltérést idézhet elő a szolgáltatás által kezelt fájlokkal.
Az sem jó első lépés, ha töröl minden Squidra hasonlító objektumot a /dev/shm alatt. Egy megnevezett objektum egy aktív példányhoz tartozhat. A tisztítást, ahol szükséges, egy igazolt, elhagyott erőforrásra kell irányítani az érintett szolgáltatás leállítása mellett, majd a szokásos szolgáltatási mechanizmuson keresztül kell elindítani.
A hasznos eredmény egy következetes indítási és tulajdonjogi modell. Egyetlen parancs rootként való futtatása addig, amíg a hiba el nem tűnik, a következő rutinszerű újraindítást pontosan ugyanazzal a problémával hagyhatja maga után.