Gibt es eine sichere Möglichkeit, verloren gegangene Unix-Socket-Dateien automatisch zu entfernen, bevor die zugehörigen Dienste ausgeführt werden?

Gibt es eine sichere Möglichkeit, verloren gegangene Unix-Socket-Dateien automatisch zu entfernen, bevor die zugehörigen Dienste ausgeführt werden?

Ich führe Daphne vom Supervisor auf Ubuntu 18.04 aus mit der --unix-socketOption, eine Bindung an einen Unix-Socket statt an einen TCP-Host/-Port vorzunehmen:

command=daphne --unix-socket /home/project/run/daphne.sock project.asgi:application

Nach einem Stromausfall blieb eine Dateiinstanz daphne.sockzurück und nach dem Neustart weigerte sich Daphne, zu starten, bis ich die fehlerhafte Datei manuell entfernte.

Gibt es eine Möglichkeit, die Datei beim Systemstart sicher zu entfernen, bevor der Supervisor ausgeführt wird?

Ich verstehe, dass dies kein spezifisches Problem von Daphne ist und auch andere Komponenten wie PostgreSQL betreffen kann. Daher wäre ich für jeden Vorschlag, Dateien zu bereinigen, bevor Dienste entweder vom Supervisor oder von systemd gestartet werden, sehr dankbar.

Antwort1

Verwendentmpfs, zB erstellen Sie die Datei darin /dev/shm.

Es soll als gemountetes Dateisystem erscheinen, aber gespeichert inflüchtiger Speicheranstelle eines dauerhaften Speichergeräts.

[Hervorhebung von mir]

In meinem Debian /runist auch tmpfsund ich kann sehen, dass einige Tools ihre Sockets dort erstellt haben. LautFHS /runist ein guter Ort für einen Socket, der von einem systemweiten Dienst erstellt wurde.

Laufzeitvariable Daten: Informationen über das laufende System seit dem letzten Bootvorgang, z. B. aktuell angemeldete Benutzer und laufende Daemons. Dateien in diesem Verzeichnis müssen zu Beginn des Bootvorgangs entweder entfernt oder gekürzt werden. Dies ist jedoch auf Systemen, die dieses Verzeichnis als temporäres Dateisystem (tmpfs) bereitstellen, nicht erforderlich.

In meinem Debian /rungehört es root und seine Modusbits (Berechtigungen) sind rwxr-xr-x. Normale Benutzer können davon nicht profitieren.

Auf der anderen Seite /dev/shmist es rwxrwxrwt, jeder kann es benutzen. Aber da es ein „gemeinsames Land“ ist (wie /tmp), treten nur wenige Probleme auf. Die Möglichkeit von Namenskonflikten ist eines davon. Zwei Benutzer können sich gegenseitig stören, auch wenn ihre Absichten vollkommen harmlos sind.

Dann ist da/run/user/$uid, ebenso wie tmpfs:

Wird zum Speichern von Dateien verwendet, die von laufenden Prozessen für diesen Benutzer verwendet werden. […]
Dieses Verzeichnis ist lokal im System und nur für den Zielbenutzer zugänglich. Anwendungen, die ihre Dateien lokal speichern möchten, müssen sich also keine Gedanken mehr über die Zugriffskontrolle machen.

verwandte Informationen