Squid shm_open: tilgang nektet — eierskapet til delt minne må sjekkes

De to meldingene Could not read pid file og shm_open(...): Permission denied kan komme i samme mislykkede oppstart av Squid. De peker på hver sin ressurs. Å rette eierskapet på en cache-mappe løser ikke i seg selv noen av dem.

Under Linux ligger et POSIX-objekt for delt minne normalt under /dev/shm. Både eier og tilgangsmodus spiller en rolle. Et objekt som er blitt stående igjen fra en annen kjørende identitet, kan derfor få en senere prosess til å feile — også når squid.conf er lesbar og porten som lyttes på er ledig.

Finn ut hvordan denne instansen ble startet

Sett den vanlige tjenestestarten opp mot en eventuell manuell start som ble brukt under feilsøkingen. Prosessen du startet for hånd, og tjenesten fra pakken, kan bruke forskjellige brukere, stier eller konfigurasjonsfiler. Avklar om en annen Squid-instans fremdeles kjører, før du regner et objekt som foreldet.

Deretter bør du lese nøyaktig hvilken operasjon som feiler. En PID-feil handler om den konfigurerte plasseringen av PID-filen og mappen over. En loggfeil handler om loggfilen eller loggmappen. En feil ved oppstart av cachen handler om lagringsmediet. En shm_open-feil handler om det navngitte objektet for delt minne, og kan i tillegg gjelde sikkerhetsreglene som er lagt på prosessen.

For hver ressurs: sammenlign tilgangen kjøretiden trenger med eieren og modusen slik de er nå. Ser de vanlige rettighetene ut til å holde, bør du se etter avvisningene i SELinux eller AppArmor. Bare “Permission denied” sier ikke hvilket lag som stoppet tilgangen.

Rett eierskapet uten å lage et nytt problem

Sørg for at kjørekontoen stemmer med tjenestekonfigurasjonen installasjonen bruker. Bytter du alt over til nobody, kan hjelpeprogrammene miste tilgang, og du får et nytt avvik mot filene tjenesten styrer.

Det er heller ikke lurt å begynne med å slette alle Squid-lignende objekter i /dev/shm. Et navngitt objekt kan tilhøre en instans som er i drift. Trengs opprydding, bør den rettes mot en ressurs du har bekreftet er forlatt, mens tjenesten det gjelder er stoppet — og deretter startes tjenesten på vanlig måte.

Det nyttige resultatet er en start- og eierskapsmodell som henger sammen. Kjører du én kommando som root til feilen er borte, kan den neste vanlige omstarten stå med akkurat samme problem.