Squid shm_open: dostop zavrnjen — preverite lastništvo deljenega pomnilnika
Ločite napake lastništva deljenega pomnilnika Squida od napak dovoljenj za PID, dnevnik in imenik predpomnilnika.
Could not read pid file in shm_open(...): Permission denied se lahko pojavita med istim neuspešnim zagonom Squida. Označujeta različne vire. Popravljanje lastništva imenika predpomnilnika samo po sebi ne odpravi nobene od njiju.
V Linuxu je predmet deljenega pomnilnika POSIX običajno predstavljen pod /dev/shm. Pomembna sta njegov lastnik in način dostopa. Predmet, ki ga je pustila druga izvajalna identiteta, lahko zato povzroči neuspeh poznejšega procesa, tudi ko je squid.conf berljiv in je vrata za poslušanje prosta.
Rekonstruirajte, kako se je ta primer zagnal
Primerjajte običajen zagon storitve z vsakim ročnim zagonom, uporabljenim med odpravljanjem težave. Ročno zagnan proces in pakirana storitev lahko uporabljata različne uporabnike, poti ali konfiguracijske datoteke. Ugotovite, ali druga instanca Squida še teče, preden predmet obravnavate kot zastarel.
Nato preberite natančno delovanje, ki ne uspe. Napaka PID se nanaša na konfigurirano mesto PID in njegov nadrejeni imenik. Napaka dnevnika se nanaša na dnevniško datoteko ali imenik. Napaka pri inicializaciji predpomnilnika se nanaša na shrambo. Napaka shm_open se nanaša na imenovani predmet deljenega pomnilnika in lahko vključuje tudi varnostno politiko, ki se uporablja za proces.
Za vsak vir primerjajte zahtevani izvajalni dostop z njegovim trenutnim lastnikom in načinom. Če se običajna dovoljenja zdijo zadostna, preglejte ustrezne dokaze o zavrnitvi v SELinuxu ali AppArmorju. Samo “Permission denied” ne pokaže, katera raven je zavrnila dostop.
Popravite lastništvo, ne da bi ustvarili drugo težavo
Vzdržujte izvajalni račun v skladu s konfiguracijo storitve namestitve. Preklop vsega na nobody lahko prekine dostop pomožnih programov in vnese novo neujemanje z datotekami, ki jih upravlja storitev.
Tudi brisanje vseh Squidu podobnih predmetov v /dev/shm ni dober prvi korak. Imenovani predmet lahko pripada aktivni instanci. Čiščenje, kadar je potrebno, naj bo usmerjeno na potrjen zapuščen vir z ustavljeno prizadeto storitvijo, nato pa zagon po običajnem mehanizmu storitve.
Koristni rezultat je dosleden model zagona in lastništva. Zagon enega ukaza kot root, dokler napaka ne izgine, lahko pusti naslednji rutinski ponovni zagon s popolnoma enako težavo.