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. Popravljanje vlasništva direktorija keša samo po sebi ne popravlja 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.
Rekonstruirajte kako je ova instanca pokrenuta
Uporedite uobičajeno pokretanje usluge sa bilo kojim ručnim pokretanjem korištenim tokom rješavanja problema. Ručno pokrenut proces i pakovana usluga mogu koristiti različite korisnike, putanje ili konfiguracijske datoteke. Utvrdite da li je druga instanca Squida još aktivna prije nego 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 sa 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.
Popravite vlasništvo bez stvaranja drugog problema
Držite račun izvršavanja usklađenim sa konfiguracijom usluge instalacije. Prebacivanje svega na nobody može pokvariti pristup pomoćnih alata i unijeti novo neslaganje sa 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 sa potpuno istim problemom.