Squid shm_open: adgang nægtet — kontroller ejerskabet af delt hukommelse
Adskil Squids fejl i ejerskab af delt hukommelse fra tilladelsesfejl i PID, log og cache-mappe.
Could not read pid file og shm_open(...): Permission denied kan optræde under den samme mislykkede Squid-opstart. De navngiver forskellige ressourcer. At rette ejerskabet af en cache-mappe løser ikke i sig selv nogen af dem.
På Linux repræsenteres et POSIX-objekt til delt hukommelse normalt under /dev/shm. Dets ejer og adgangstilstand har betydning. Et objekt, der er efterladt af en anden kørende identitet, kan derfor få en senere proces til at fejle, selv når squid.conf er læsbar, og den lyttende port er fri.
Rekonstruer, hvordan denne instans blev startet
Sammenlign den normale tjenestestart med enhver manuel start, der blev brugt under fejlfindingen. En manuelt startet proces og den pakkede tjeneste kan bruge forskellige brugere, stier eller konfigurationsfiler. Fastslå, om en anden Squid-instans stadig kører, før et objekt betragtes som forældet.
Læs derefter den præcise fejlende handling. En PID-fejl vedrører den konfigurerede PID-placering og dens overordnede mappe. En logfejl vedrører logfilen eller mappen. En cache-initialiseringsfejl vedrører lageret. En shm_open-fejl vedrører det navngivne objekt til delt hukommelse og kan også involvere den sikkerhedspolitik, der anvendes på processen.
Sammenlign for hver ressource den krævede kørselsadgang med dens nuværende ejer og tilstand. Hvis almindelige tilladelser ser tilstrækkelige ud, undersøg de relevante afvisningsbeviser i SELinux eller AppArmor. “Permission denied” alene viser ikke, hvilket lag der afviste adgangen.
Ret ejerskabet uden at skabe et nyt problem
Hold kørselskontoen i overensstemmelse med installationens tjenestekonfiguration. At skifte alt til nobody kan bryde hjælpeadgang og skabe en ny uoverensstemmelse med tjenestestyrede filer.
Det er heller ikke et godt første skridt at slette ethvert Squid-lignende objekt i /dev/shm. Et navngivet objekt kan tilhøre en aktiv instans. Oprydning bør, hvor det er nødvendigt, målrettes en bekræftet forladt ressource med den berørte tjeneste stoppet, efterfulgt af start via den normale tjenestemekanisme.
Det nyttige resultat er en konsistent start- og ejerskabsmodel. At køre én kommando som root, indtil fejlen forsvinder, kan efterlade den næste rutinemæssige genstart med præcis det samme problem.