Nachdem ein Befehl zum Herunterfahren ausgegeben wurde, erhält man manchmal eine Statusmeldung wie diese:
A stop job is running for Session 1 of user xy
und dann hängt das System für eine Weile oder für immer, abhängig von ???
Was genau ist also ein „Stopp-Job“?
Außerdem, warum schätzt es manchmal ziemlich genau die Zeit, die es brauchen wird, und manchmal kann es ewig dauern?
Akzeptierte Antwort:
systemd arbeitet intern in Form einer Warteschlange von „Jobs“. Jeder Auftrag (etwas vereinfacht) ist eine auszuführende Aktion:eine bestimmte Einheit anhalten, prüfen, starten oder neu starten .
Wenn Sie (zum Beispiel) systemd anweisen, eine Diensteinheit zu starten , erstellt es eine Liste von Stopp- und Start-Jobs für alle Einheiten (Service-Einheiten, Mount-Einheiten, Geräteeinheiten usw.), die zum Erreichen dieses Ziels erforderlich sind, gemäß den Anforderungen und Abhängigkeiten der Einheiten, und ordnet sie gemäß den Ordnungsbeziehungen der Einheiten an , arbeitet und (wenn möglich) alle Selbstwidersprüche aus und stellt sie (wenn dieser letzte Schritt erfolgreich ist) in die Warteschlange.
Dann versucht es, die eingereihten „Jobs“ auszuführen.
Für Sitzung 1 von Benutzer xy wird ein Stoppjob ausgeführt
Der Anzeigename der Einheit hier ist Session 1 of user xy . Dies wird (vom Anzeigenamen her) eine Sitzung sein Einheit, kein Dienst Einheit. Dies ist die Benutzerraum-Anmeldesitzungsabstraktion, die von systemds logind verwaltet wird Programm und seine PAM-Plugins. Es ist (im Wesentlichen und theoretisch) eine Gruppierung aller Prozesse, die dieser Benutzer irgendwo als „Anmeldesitzung“ ausführt.
Der Job, der dagegen eingereiht wurde, ist stop . Und es dauert wahrscheinlich lange, weil die Systemd-Leute fälschlicherweise die Sitzung hangup zusammengeführt haben mit Sitzung Herunterfahren . Sie brechen Ersteres, um Letzteres zum Laufen zu bringen, und als Reaktion darauf ändern einige Leute systemd, um Letzteres zu brechen, um Ersteres zum Laufen zu bringen. Die Systemd-Leute sollten wirklich erkennen, dass sie zwei verschiedene Dinge sind.
In Ihrer Anmeldesitzung haben Sie etwas, das SIGTERM ignoriert oder es dauert lange, bis es beendet wird, nachdem es SIGTERM gesehen hat . Ironischerweise ist Ersteres das langjährige Verhalten einiger Job-Control-Shells. Der richtige Weg, Anmeldesitzungsleiter zu beenden, wenn es sich um diese speziellen Job-Control-Shells handelt, besteht darin, ihnen mitzuteilen, dass die Sitzung aufgehängt wurde , woraufhin sie alle ihre beenden Jobs (eine andere Art von Job als der interne systemd-Job) und beenden sich dann selbst.
Was tatsächlich passiert, ist, dass systemd auf das Stopp-Timeout der Einheit wartet bis es auf SIGKILL zurückgreift . Dieses Timeout ist natürlich pro Einheit konfigurierbar und kann so eingestellt werden, dass es niemals abläuft. Daher kann man möglicherweise unterschiedliche Verhaltensweisen sehen.
Weiterführende Literatur
- Lennart Pöttering (2015). systemd. systemd Handbuchseiten. Freedesktop.org.
- Jonathan de Boyne Pollard (2016-06-01). systemd beendet Hintergrundprozesse, nachdem sich der Benutzer abgemeldet hat . 825394. Debian-Fehlerverfolgung.
- Lennart Pöttering (2015). systemd.kill. systemd Handbuchseiten. Freedesktop.org.
- Lennart Pöttering (2015). systemd.service. systemd Handbuchseiten. Freedesktop.org.
- Warum ignoriert Bash SIGTERM?
- https://superuser.com/questions/1102242/