Squid shm_open: Zugriff verweigert — Eigentümer des gemeinsamen Speichers prüfen
Trennen Sie Eigentumsfehler beim gemeinsamen Speicher von Squid von Berechtigungsfehlern bei PID, Log und Cache-Verzeichnis.
Could not read pid file und shm_open(...): Permission denied können beim selben fehlgeschlagenen Squid-Start auftreten. Sie benennen unterschiedliche Ressourcen. Das Korrigieren der Eigentümerschaft eines Cache-Verzeichnisses behebt für sich genommen keines von beiden.
Unter Linux wird ein POSIX-Objekt für gemeinsamen Speicher üblicherweise unter /dev/shm dargestellt. Eigentümer und Zugriffsmodus sind entscheidend. Ein von einer anderen Laufzeitidentität hinterlassenes Objekt kann daher einen späteren Prozess scheitern lassen, selbst wenn squid.conf lesbar und der lauschende Port frei ist.
Rekonstruieren Sie, wie diese Instanz gestartet wurde
Vergleichen Sie den normalen Dienststart mit jedem manuellen Start, der bei der Fehlersuche verwendet wurde. Ein manuell gestarteter Prozess und der paketierte Dienst können unterschiedliche Benutzer, Pfade oder Konfigurationsdateien verwenden. Stellen Sie fest, ob noch eine andere Squid-Instanz läuft, bevor Sie ein Objekt als verwaist behandeln.
Lesen Sie dann den genauen fehlschlagenden Vorgang. Ein PID-Fehler betrifft den konfigurierten PID-Ort und dessen übergeordnetes Verzeichnis. Ein Log-Fehler betrifft die Logdatei oder das Verzeichnis. Ein Fehler bei der Cache-Initialisierung betrifft den Speicher. Ein shm_open-Fehler betrifft das benannte Objekt für gemeinsamen Speicher und kann auch die auf den Prozess angewandte Sicherheitsrichtlinie einschließen.
Vergleichen Sie für jede Ressource den erforderlichen Laufzeitzugriff mit ihrem aktuellen Eigentümer und Modus. Erscheinen gewöhnliche Berechtigungen ausreichend, prüfen Sie die einschlägigen Verweigerungsnachweise von SELinux oder AppArmor. “Permission denied” allein zeigt nicht, welche Schicht den Zugriff verweigert hat.
Beheben Sie die Eigentümerschaft, ohne ein zweites Problem zu schaffen
Halten Sie das Laufzeitkonto mit der Dienstkonfiguration der Installation konsistent. Alles auf nobody umzustellen kann den Zugriff von Hilfsprogrammen brechen und eine neue Abweichung zu dienstverwalteten Dateien einführen.
Auch das Löschen jedes Squid-artigen Objekts in /dev/shm ist kein guter erster Schritt. Ein benanntes Objekt kann zu einer aktiven Instanz gehören. Eine Bereinigung sollte, wo nötig, auf eine bestätigt verlassene Ressource zielen, während der betroffene Dienst gestoppt ist, gefolgt von einem Start über den normalen Dienstmechanismus.
Das nützliche Ergebnis ist ein konsistentes Start- und Eigentumsmodell. Ein einzelner Befehl als root, bis der Fehler verschwindet, kann den nächsten routinemäßigen Neustart mit genau demselben Problem hinterlassen.