Squid shm_open: åtkomst nekad — kontrollera ägandet av delat minne
Skilj Squids ägandefel för delat minne från behörighetsfel för PID, logg och cachemapp.
Could not read pid file och shm_open(...): Permission denied kan uppträda vid samma misslyckade Squid-start. De namnger olika resurser. Att rätta ägandet av en cachemapp löser inte i sig någon av dem.
I Linux representeras ett POSIX-objekt för delat minne vanligtvis under /dev/shm. Ägaren och åtkomstläget spelar roll. Ett objekt som lämnats av en annan körande identitet kan därför få en senare process att misslyckas, även när squid.conf är läsbar och den lyssnande porten är ledig.
Rekonstruera hur den här instansen startades
Jämför den normala tjänstestarten med varje manuell start som användes under felsökningen. En manuellt startad process och den paketerade tjänsten kan använda olika användare, sökvägar eller konfigurationsfiler. Fastställ om en annan Squid-instans fortfarande kör innan ett objekt behandlas som föråldrat.
Läs sedan den exakta operation som misslyckas. Ett PID-fel gäller den konfigurerade PID-platsen och dess överordnade mapp. Ett loggfel gäller loggfilen eller mappen. Ett fel vid cacheinitiering gäller lagringen. Ett shm_open-fel gäller det namngivna objektet för delat minne och kan även omfatta säkerhetspolicyn som tillämpas på processen.
Jämför för varje resurs den åtkomst som krävs vid körning med dess nuvarande ägare och läge. Om vanliga behörigheter verkar räcka, granska relevanta avslagsbevis i SELinux eller AppArmor. Enbart “Permission denied” visar inte vilket lager som nekade åtkomst.
Reparera ägandet utan att skapa ett nytt problem
Håll körkontot konsekvent med installationens tjänstekonfiguration. Att byta allt till nobody kan bryta hjälpprogrammens åtkomst och införa en ny bristande överensstämmelse med tjänstestyrda filer.
Det är inte heller ett bra första steg att radera varje Squid-liknande objekt i /dev/shm. Ett namngivet objekt kan tillhöra en aktiv instans. Städning bör, där det behövs, riktas mot en bekräftat övergiven resurs med den berörda tjänsten stoppad, följt av start via den normala tjänstemekanismen.
Det användbara resultatet är en konsekvent start- och ägandemodell. Att köra ett enda kommando som root tills felet försvinner kan lämna nästa rutinmässiga omstart med exakt samma problem.