Squid shm_open: acces refuzat — verificați proprietatea memoriei partajate
Separați defecțiunile de proprietate a memoriei partajate Squid de erorile de permisiuni pentru PID, jurnal și directorul de cache.
Could not read pid file și shm_open(...): Permission denied pot apărea în timpul aceleiași porniri eșuate a Squid. Ele numesc resurse diferite. Corectarea proprietății unui director de cache nu rezolvă, prin ea însăși, niciuna dintre ele.
În Linux, un obiect de memorie partajată POSIX este reprezentat de obicei sub /dev/shm. Proprietarul și modul de acces contează. Un obiect lăsat de o altă identitate de execuție poate provoca astfel eșecul unui proces ulterior, chiar și atunci când squid.conf este lizibil, iar portul de ascultare este liber.
Reconstituiți modul în care a pornit această instanță
Comparați pornirea normală a serviciului cu orice pornire manuală folosită în timpul diagnosticării. Un proces pornit manual și serviciul împachetat pot folosi utilizatori, căi sau fișiere de configurare diferite. Stabiliți dacă o altă instanță Squid încă rulează înainte de a trata un obiect ca învechit.
Apoi citiți operațiunea exactă care eșuează. O eroare PID privește locația configurată a PID-ului și directorul său părinte. O eroare de jurnal privește fișierul sau directorul de jurnal. O eroare de inițializare a cache-ului privește stocarea. O eroare shm_open privește obiectul de memorie partajată cu nume și poate implica și politica de securitate aplicată procesului.
Pentru fiecare resursă, comparați accesul de execuție necesar cu proprietarul și modul actuale. Dacă permisiunile obișnuite par suficiente, examinați dovezile de refuz relevante din SELinux sau AppArmor. Doar “Permission denied” nu indică ce nivel a refuzat accesul.
Reparați proprietatea fără a crea o a doua problemă
Mențineți contul de execuție consecvent cu configurația serviciului din instalare. Trecerea tuturor la nobody poate rupe accesul programelor auxiliare și poate introduce o nouă nepotrivire cu fișierele administrate de serviciu.
Nici ștergerea fiecărui obiect care pare a fi Squid din /dev/shm nu este un prim pas bun. Un obiect cu nume poate aparține unei instanțe active. Curățarea, atunci când este necesară, ar trebui să vizeze o resursă abandonată confirmată, cu serviciul afectat oprit, urmată de pornirea prin mecanismul normal al serviciului.
Rezultatul util este un model consecvent de pornire și proprietate. Rularea unei singure comenzi ca root până când eroarea dispare poate lăsa următoarea repornire de rutină cu exact aceeași problemă.