Squid shm_open: tilgang nektet — kontroller eierskapet til delt minne
Skill Squids feil i eierskap av delt minne fra tillatelsesfeil i PID, logg og cache-mappe.
Could not read pid file og shm_open(...): Permission denied kan oppstå under samme mislykkede Squid-start. De navngir forskjellige ressurser. Å rette eierskapet til en cache-mappe løser ikke i seg selv noen av dem.
På Linux representeres et POSIX-objekt for delt minne vanligvis under /dev/shm. Eier og tilgangsmodus har betydning. Et objekt som er etterlatt av en annen kjøreidentitet kan derfor få en senere prosess til å feile, selv når squid.conf er lesbar og den lyttende porten er ledig.
Rekonstruer hvordan denne instansen startet
Sammenlign den normale tjenestestarten med enhver manuell start som ble brukt under feilsøkingen. En manuelt startet prosess og den pakkede tjenesten kan bruke forskjellige brukere, stier eller konfigurasjonsfiler. Fastslå om en annen Squid-instans fortsatt kjører før et objekt behandles som utdatert.
Les deretter den nøyaktige feilende operasjonen. En PID-feil gjelder den konfigurerte PID-plasseringen og overordnet mappe. En loggfeil gjelder loggfilen eller mappen. En feil ved cache-initialisering gjelder lagringen. En shm_open-feil gjelder det navngitte objektet for delt minne og kan også omfatte sikkerhetspolicyen som brukes på prosessen.
Sammenlign for hver ressurs den nødvendige kjøretilgangen med dens nåværende eier og modus. Hvis vanlige tillatelser ser tilstrekkelige ut, undersøk de relevante avvisningsbevisene i SELinux eller AppArmor. “Permission denied” alene viser ikke hvilket lag som avviste tilgangen.
Rett eierskapet uten å skape et nytt problem
Hold kjørekontoen i samsvar med tjenestekonfigurasjonen i installasjonen. Å bytte alt til nobody kan bryte hjelpeprogramtilgang og innføre et nytt avvik med tjenestestyrte filer.
Det er heller ikke et godt første steg å slette alle Squid-lignende objekter i /dev/shm. Et navngitt objekt kan tilhøre en aktiv instans. Opprydding bør, der det er nødvendig, rettes mot en bekreftet forlatt ressurs med den berørte tjenesten stoppet, etterfulgt av start via den normale tjenestemekanismen.
Det nyttige resultatet er en konsistent start- og eierskapsmodell. Å kjøre én kommando som root til feilen forsvinner, kan etterlate den neste rutinemessige omstarten med nøyaktig samme problem.