Ist / var / run / user / $ UID das neue / var / run für PID-Dateien?

3489
TSG

Ich habe eine Anwendung (läuft als Dienst als root), unter der eine PID-Datei erstellt wird /var/run. Aber ich frage mich, ob das jetzt keine Best Practice ist.

In Linux - alternative Orte, an denen die PID- Datei anstelle von / var / run gespeichert werden soll (2012), fragt der Fragesteller, ob PID-Dateien überhaupt eingefügt werden sollen /var/run. Dies war jedoch weitgehend vor dem Aufkommen von systemd und dem Umstieg auf systemd-Betriebssysteme von /var/runnur /run(als eines der systemd " API-Dateisysteme " und in den systemd File-Hierarchy-Anforderungen aufgeführt ).

Dinge wie die XDG-Basisverzeichnisspezifikation von Lennart Poettering (und andere) sprechen von anderen Stellen für "benutzerspezifische, nicht unbedingt erforderliche Laufzeitdateien und andere Dateiobjekte (wie Sockets, Named Pipes, ...)". Ebenso die systemd- file-hierarchyHandbuchseite .

Was ich an anderer Stelle gelesen habe, vermittelt mir den Eindruck, dass dies /var/run/user/$UIDein neuer Standardstandort für solche Dinge auf systemd Betriebssystemen ist.

  • Die Antworten in https://unix.stackexchange.com/questions/162900/ beziehen sich auf "Dateien, die zum Ausführen von Prozessen verwendet werden". Es wird vorgeschlagen, dass / var / run / user / 0 der geeignete Speicherort ist, wenn das Programm als root ausgeführt wird. In diesem Beitrag wird jedoch auch angegeben, dass das Verzeichnis entfernt / gelöscht wird, wenn keine aktiven Sitzungen mehr vorhanden sind. Ist dies wirklich der richtige Ort?
  • https://github.com/systemd/systemd/issues/735#issuecomment-126309537 zeigt einen Prozess, der von systemd mit den Befehlszeilenargumenten aufgerufen wird--pid-file /run/user/1000/uzbl/event/pid
  • https://lists.debian.org/debian-user/2015/10/msg01315.html, eine Diskussion in der Debian-Benutzer-Mailingliste, hat eine Person, die besagt, dass "der vollständige Freedesktop-Montierer" für PID-Dateien "[ies]" angibt. /run/userdafür".

Man kann viele andere Beispiele finden.

Sollte meine Anwendung also geändert werden /var/run/user/$UID? Da es sich um einen Dienst (keine aktive Sitzung) handelt, löscht / entfernt pam_systemd das Verzeichnis? Oder $XDG_RUNTIME_DIR? Ist das etwas, das systemd-spezifisch ist? Oder ist es ein neuer Standard für alle Unices?

Was ist die beste Methode heutzutage bei systemd Betriebssystemen? Trifft dies im Allgemeinen auch für andere Betriebssysteme zu (nicht systemd, aber Unix-ähnlich)?

4
Jemand hat es geschafft, die Frage innerhalb von 10 Sekunden nach dem Posten abzustimmen. TSG vor 8 Jahren 0
Läuft Ihr Dienst pro Benutzer? Oder ist es ein Systemdienst? Oder ist systemd vielleicht doch nicht beteiligt? Daniel B vor 8 Jahren 1
Mögliches Duplikat von [Linux - alternative Speicherorte für die PID-Datei anstelle von /var/run? (Http: //www.superuser.com/questions/454449/linux-alternative-places-where-to-store-pid-file-instead) -of-var-run) Xavierjazz vor 8 Jahren 0
Ich habe die andere SU-Antwort oben aufgeführt, aber sie verweist nicht auf / var / run / user / $ uid, weshalb ich diese Frage geöffnet habe TSG vor 8 Jahren 0
Angesichts der vom Fragesteller hinzugefügten Tags ist es ziemlich klar, dass systemd involviert ist. Es ist auch ziemlich klar, dass der Fragesteller nicht nach den Alternativen gefragt hat, sondern ob das, was xe über neue systemd-Konventionen geschlossen hat, richtig ist. Haben Sie eine Frage, die dies klarer machen sollte. JdeBP vor 8 Jahren 0
Es ist überhaupt nicht klar, @JdeBP. Manchmal werden Tags fälschlicherweise hinzugefügt. Ich denke auch, dass dein Schnitt viel zu groß ist. Wenn das OP nicht die Informationen bereitstellt, nach denen ich gefragt habe, kann die Frage einfach nicht beantwortet werden. Daniel B vor 8 Jahren 0
Die Änderungen sehen gut aus - sicherlich besser als ich es ausdrücken könnte. Jetzt gibt es hoffentlich eine ebenso gute Antwort .... TSG vor 8 Jahren 0
"Was ist Best Practice heutzutage", macht diese Frage auf der Grundlage der Meinung. Und wenn Sie dieses Stück entfernt haben, ist die Frage zu umfassend. So oder so sollte es geschlossen sein. DavidPostill vor 8 Jahren 0
@DanielB - das Programm wird als Dienst ausgeführt (aktualisierte Frage) TSG vor 8 Jahren 0

2 Antworten auf die Frage

5
Tino

Du fragst:

Ist / var / run / user / $ UID das neue / var / run für PID-Dateien?

Die kurze Antwort lautet "Nein".

Und die lange Antwort ist immer noch "nein".

Oder um es klar und deutlich zu sagen: Traditionelle PID-Dateien dürfen nicht unterschreiten/run/user/$UID/ (AKA /var/run/user/$UID/). Halten Sie sie in /run/oder /run/package/wie üblich, als /run/user/$UID/einen völlig anderen Zweck für Sitzungsdienste dient.

Zu Ihrer Information:

  • Wie von @Daniel B angemerkt, ist /var/runheute ein Softlink, auf den verwiesen wird /run. Dies ist systemdfür die meisten heutigen Systeme nicht spezifisch und kann in diesen Systemen gefunden werden. Wenn Sie mit alten Systemen kompatibel bleiben möchten, gibt es zwei Lösungen: Entweder bleiben Sie bei /var/run/statt /run/oder lassen Sie einen Softlink erstellen /run, auf den /var/runauf solche alten Systeme verwiesen wird.

  • Bitte beachten Sie auch, dass dies /run/user/$UID/für Systeme gilt, die ausgeführt werden systemd-logind. Es wird auch nicht auf älteren Systemen unterstützt.

Um für diejenigen ins Detail zu gehen, die noch nicht wissen:

Es gibt drei Arten von Diensten: Systemdienste, Benutzerdienste und Sitzungsdienste. Alle 3 Typen können entweder im Hintergrund oder im Vordergrund ausgeführt werden, so dass sich 6 Varianten ergeben.

Vordergrundsystemdienste wurden traditionell von gestartet /etc/inittab, heute werden systemdsie über gestartet /etc/init/. Vordergrundsystemdienste benötigen normalerweise keine PID-Dateien, da sie von diesen kontrolliert werden initund bei einem Ausfall erneut erzeugt werden können.

Hintergrundsystemdienste wurden traditionell mit den Runlevel-Skripts gestartet /etc/rc.d/. Diese benötigen in der Regel PID-Dateien, da sie im Hintergrund ausgeführt werden. Daher können sie nicht gesteuert werden. PID-Dateien sind sehr fehleranfällig (da es keine Garantie dafür gibt, dass die PID nach Beendigung des Diensts frei bleibt) und werden verwendet, um die gestarteten Dienste erneut zu finden, wenn das rc-script den Dienst herunterfahren muss. Diese PID-Dateien haben traditionell gewohnt /var/runund leben heutzutage in /run/package/(oder, wenn es nur eine einzige Datei pro Paket gibt, in /run/package.pid).

Benutzerdienste sind Dienste, die von einem Benutzer gestartet werden und über die Sitzung des Benutzers hinaus leben müssen. Zum Beispiel ein Minecraft-Server oder so etwas wie ein langjähriger SAP-Abfrageprozess, der bei Bedarf durch eine kurzlebige Sitzung ausgelöst wird. Sie unterscheiden sich ein wenig von Systemdiensten, da sie nicht verwendet werden können /run/. Stattdessen müssen sie /tmp/oder ein Verzeichnis darunter verwenden $HOME(was problematisch ist, wenn $HOMEes sich um eine Netzwerkfreigabe handelt, die von mehreren Computern gemeinsam genutzt wird).

Vordergrundbenutzerdienste sind manchmal etwas problematisch, da sie häufig eine benötigen. ttyWenn sich der Benutzer abmeldet, werden sie beendet. Daher gibt es zahlreiche Möglichkeiten, sie nach dem Ablegen des Benutzers leben zu lassen, wie nohupoder screen. Es kann aber auch einige exotische Varianten geben socat tcp-connect:host:port exec:service.sh,pty.

Eine andere Variante der Vordergrundbenutzerdienste sind Cron-Jobs, die in crontabdem Benutzer leben. Diese Cronjobs können jedoch auch Hintergrunddienste sein, zum Beispiel wenn sie nicht parallel ausgeführt werden sollen, selbst wenn ein Prozess die Zeit überschreitet, wenn der nächste Aufruf von cron erfolgt.

Hintergrundbenutzerdienste haben das gleiche Problem wie Hintergrundsystemdienste, da sie verfolgen müssen, welche bereits ausgeführt werden und bereits laufende Dienste steuern. In der Vergangenheit hat dies zu verschiedenen Problemen und Korrekturen für Dinge wie Verzeichnisdurchquerungsangriffe und ähnliches geführt, da /tmpdort alle Dateien und Verzeichnisse erstellt werden können.

Dies hat sich jedoch noch nicht geändert, da dies /run/user/$UID/nicht für solche Benutzerdienste gedacht ist. Es wurde entwickelt, um ein noch schwierigeres Problem mit Sitzungsdiensten zu lösen.

Ein Sitzungsdienst ist ein Dienst, der normalerweise mit der Anmeldung des Benutzers gestartet und mit der Abmeldung des Benutzers beendet wird. Das klingt einfach, gewinnt aber an Bedeutung, wenn pro Benutzer mehr als nur eine Sitzung erlaubt ist. Die schwierig zu lösende Frage lautet: "Wann endet eine Sitzung wirklich?"

Eine Sitzung beginnt mit der ersten Anmeldung. Das ist leicht zu verstehen. Es endet jedoch nicht unbedingt, wenn sich dieser Login abmeldet! Der Sitzungsdienst kann also mit der ersten Anmeldung (oder später) gestartet werden, muss jedoch häufig weiter ausgeführt werden, bis sich die letzte Sitzung des Benutzers abmeldet.

Vordergrundsitzungsdienste sind normalerweise die einfache Variante. Wie der X-Window- dbusDienst, der mit dem grafischen Login gestartet und beendet wird. Wenn Sie jedoch ein riesiges PDF-Dokument drucken, möchten Sie sicher, dass dieser Job erfolgreich abgeschlossen wird oder sauber beendet wird, ohne dass Rückstände zurückbleiben, oder?

Diese Art von Sitzungsdiensten muss entweder weiterhin im Hintergrund ausgeführt werden, oder es muss eine Möglichkeit zum Bereinigen vorhanden sein, nachdem der Dienst abgeschaltet wurde, wenn unerwartete Dinge zum Erliegen kommen. Und in unserer mobilen Welt sterben oft Dinge. Denken Sie an Ihren Monitor. Sie können einen Monitor jederzeit ein- und ausstecken. Der Computer muss nicht neu gestartet werden. Aber was passiert, wenn Sie alle Bildschirme entfernen? Nun, natürlich stirbt X11. Für einige Benutzerdienste, die in der X11-Sitzung ausgeführt werden, kommt dies unerwartet, möglicherweise mitten in einer länger laufenden Task.

Dies ist von /run/user/$UID/Nutzen, da dieses Verzeichnis nach Beendigung der letzten Benutzersitzung automatisch gelöscht wird. So können Dienste darauf vertrauen, dass sich hinter dem Benutzer eine Bereinigung für alles, was darin gespeichert ist, befindet /run/user/$UID/!

Daher sollten alle sitzungsbezogenen Dienste dieses Verzeichnis verwenden.

Bitte beachten Sie auch, dass wir dbusheute haben. Sie müssen sich also nicht mehr auf PID-Dateien verlassen, nur um herauszufinden, ob ein Dienst ausgeführt wird oder nicht. Dies gilt insbesondere für Sitzungsdienste, da es etwas gibt, das als "Sitzung" bezeichnet wird. Dadurch können Sie die Dinge ein bisschen besser handhaben, z. B. Shared-Memory-Segmente oder Sperrdateien, in denen Sie leben können /run/user/$UID/.

Die Dinge sind nicht einfach. Und um es noch ein bisschen komplexer zu machen, gibt es Dinge wie screen( tmuxoder sshderjenige, der sich von der Shell abhebt), der zwei Seiten hat, eine Seite ist ein Benutzerdienst (d. H. Der Dämon), die andere Seite ist ein Sitzungsdienst (die tty). Während sie normalerweise an eine Sitzung gebunden sind, muss dies nicht immer der Fall sein. Wenn Sie beispielsweise die sshPortweiterleitung verwenden und die Shell verlassen, sshbleibt sie geöffnet, bis der letzte weitergeleitete Port geschlossen wird. Sie können sogar neue Ports öffnen, solange andere aktiv bleiben. Im Falle eines solchen "dualen" Dienstes kann eine PID-Datei hilfreich sein, in diesem Fall könnte sie sogar darunter liegen /run/user/$UID/.

(Beachten Sie, dass crondies zum Öffnen einer Benutzersitzung verwendet werden kann, daher wahrscheinlich /run/user/$UID/auch für Cronjobs verfügbar ist. Wenn dies jedoch der Fall ist, /run/user/$UID/wird die Bereinigung wieder möglich, nachdem alle Cronjobs abgeschlossen wurden. Dies bedeutet möglicherweise, dass Dateien, die übergeben wurden, verschwinden anderswo als anderswo, /tmp/da nur ein Neustart Dateien unbedingt dort entfernen muss.)

Etwas zusammenfassen:

Wenn Sie über einen ordnungsgemäß konzipierten Dienst verfügen, benötigen Sie niemals reine PID-Dateien /run/user/$UID/, da Sitzungsdienste (die einzigen, die dieses Verzeichnis verwenden) normalerweise eine bessere Methode (die Sitzung) haben, um die Kontrolle zu behalten, selbst wenn sie im Hintergrund ausgeführt werden .

Also, wenn Sie die Notwendigkeit einer PID - Datei für Ihren Dienst zu sehen, ist es sehr wahrscheinlich, dass Sie am Ende mit etwas wie /run/package/, /run/package.pidoder /tmp/package-$UID/.

Verwenden /run/user/$UID/Sie diese Option nur, wenn Sie sicherstellen möchten, dass die Datei verschwindet, sobald sich der Benutzer vollständig abmeldet. Beachten Sie auch, dass der rootBenutzer nicht immer angemeldet ist, so dass es wahrscheinlich keine gibt /run/user/0/.

Und bitte erstellen Sie niemals die Verzeichnisse direkt unter /run/user/sich!

Hoffentlich ist jetzt alles so schön und klar. Aber ich muss etwas gestehen:

Ich habe dich angelogen. Und ich tat es witzig (aber frei von schlechten Absichten).

Da eine Sitzung (aus systemd-logindSicht der Perspektive) nicht nur an eine gebunden ist login. Ja, etwas ähnliches loginist natürlich involviert, aber die Dinge sind ein bisschen komplexer:

https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/

Jedoch:

  • Für dieses Posting hier (die kurze, aber falsche Geschichte) lautet die Antwort auf Ihre Frage "Nein".

  • Glücklicherweise bleibt die Antwort bei den langen (und wahren) Hintergründen zu Sitzungen (siehe Link) immer "nein".

  • Nur für einige sehr wenige und sehr spezielle Fälle zu einem sehr genau definierten Zweck können Sie in Betracht ziehen, Ihre PID-Datei in einzufügen /run/user/$UID/.

Einen schönen Tag noch.

0
Daniel B

The systemd.exec manual says the following about its RuntimeDirectory option:

Takes a list of directory names. If set, one or more directories by the specified names will be created below /run (for system services) or below $XDG_RUNTIME_DIR (for user services) when the unit is started, and removed when the unit is stopped.

Additionally, on the pam_systemd man page , we can find the following information about $XDG_RUNTIME_DIR (emphasis mine):

Path to a user-private user-writable directory that is bound to the user login time on the machine. It is automatically created the first time a user logs in and removed on the user's final logout.

Using these two manuals, we can deduce that $XDG_RUNTIME_DIR (/run/user/$UID on my Arch install) is not the right choice for system services. Instead, they are usually put in /run (at least on Arch and Gentoo). It may also be feasible to create them in a RuntimeDirectory as described above.

/var/run is but a symlink to /run these days.

Verwandte Probleme