Squid shm_open: pristup odbijen — provjerite vlasništvo dijeljene memorije
Odvojite kvarove vlasništva dijeljene memorije Squida od grešaka dozvola za PID, dnevnik i direktorij keša.
Could not read pid file i shm_open(...): Permission denied mogu se pojaviti tokom istog neuspjelog pokretanja Squida. Oni imenuju različite resurse. Ispravljanje vlasništva direktorija keša samo po sebi ne ispravlja nijedno od njih.
Na Linuxu je POSIX objekat dijeljene memorije obično predstavljen pod /dev/shm. Njegov vlasnik i način pristupa su važni. Objekat koji je ostavio drugi identitet izvršavanja može zato izazvati neuspjeh kasnijeg procesa, čak i kada je squid.conf čitljiv i port za slušanje slobodan.
Rekonstruišite kako je ova instanca pokrenuta
Uporedite uobičajeno pokretanje usluge s bilo kojim ručnim pokretanjem korištenim tokom rješavanja problema. Ručno pokrenut proces i pakirana usluga mogu koristiti različite korisnike, putanje ili konfiguracijske datoteke. Utvrdite da li je druga instanca Squida još aktivna prije nego što objekat smatrate zastarjelim.
Zatim pročitajte tačnu operaciju koja nije uspjela. Greška PID-a odnosi se na konfigurisanu lokaciju PID-a i njen nadređeni direktorij. Greška dnevnika odnosi se na datoteku ili direktorij dnevnika. Greška inicijalizacije keša odnosi se na pohranu. Greška shm_open odnosi se na imenovani objekat dijeljene memorije i može uključivati i sigurnosnu politiku primijenjenu na proces.
Za svaki resurs uporedite potreban pristup u izvršavanju s trenutnim vlasnikom i načinom. Ako se uobičajene dozvole čine dovoljnim, pregledajte odgovarajuće dokaze odbijanja u SELinuxu ili AppArmoru. Samo “Permission denied” ne pokazuje koji je sloj odbio pristup.
Ispravite vlasništvo bez stvaranja drugog problema
Držite račun izvršavanja usklađenim s konfiguracijom usluge instalacije. Prelazak svega na nobody može pokvariti pristup pomoćnih alata i unijeti novo neslaganje s datotekama kojima upravlja usluga.
Ni brisanje svakog objekta nalik Squidu u /dev/shm nije dobar prvi potez. Imenovani objekat može pripadati aktivnoj instanci. Čišćenje, kada je potrebno, treba ciljati potvrđeni napušteni resurs uz zaustavljenu pogođenu uslugu, a zatim pokretanje kroz uobičajeni mehanizam usluge.
Koristan rezultat je dosljedan model pokretanja i vlasništva. Pokretanje jedne naredbe kao root dok greška ne nestane može ostaviti sljedeće rutinsko ponovno pokretanje s potpuno istim problemom.