Was genau ist "ein Stoppjob", wie in "Ein Stoppjob läuft ..."?

Nachdem ein Befehl zum Herunterfahren ausgegeben wurde, wird manchmal eine Statusmeldung wie die folgende angezeigt:

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 je nachdem ???

Also, was genau ist "ein Stoppjob"?

Warum schätzt es manchmal die Zeit, die es dauern wird, ziemlich genau und manchmal kann es für immer laufen?

systemd arbeitet intern in einer Warteschlange von "Jobs". Jeder Job (ein wenig vereinfacht) ist eine Aktion, die ausgeführt werden muss: Anhalten, Überprüfen, Starten oder Neustarten einer bestimmten Einheit .

Wenn Sie beispielsweise systemd anweisen, eine Serviceeinheit zu starten , erstellt es eine Liste mit Stopp- und Startaufträgen für die Einheiten (Serviceeinheiten, Mounteinheiten, Geräteeinheiten usw.), die zur Erreichung dieses Ziels erforderlich sind Anforderungen und Abhängigkeiten von Einheiten ordnen sie gemäß den Beziehungen zwischen Einheiten und Ordnungen an, klären (wenn möglich) etwaige Selbstwidersprüche und stellen sie (wenn dieser letzte Schritt erfolgreich ist) in die Warteschlange.

Dann wird versucht, die in die Warteschlange gestellten "Jobs" auszuführen.

Für Sitzung 1 von Benutzer xy wird ein Stoppjob ausgeführt

Der Anzeigename der Einheit lautet hier Session 1 of user xy. Dies ist (nach dem Anzeigenamen) eine Sitzungseinheit , keine Serviceeinheit . Dies ist die Abstraktion der Anmeldesitzung für den Benutzerbereich, die vom logindProgramm von systemd und seinen PAM-Plug-ins verwaltet wird. Es ist (im Wesentlichen und in der Theorie) eine Gruppierung aller Prozesse, die dieser Benutzer als "Anmeldesitzung" irgendwo ausführt.

Der Job, der in die Warteschlange gestellt wurde, ist stop. Und es dauert wahrscheinlich lange, weil die System-Leute den Sitzungsabbruch fälschlicherweise mit dem Herunterfahren der Sitzung in Konflikt gebracht haben . Sie brechen die ersteren, um die letzteren zum Arbeiten zu bringen, und als Reaktion darauf ändern einige Leute das System, um die letzteren zu brechen, um die ersteren zum Arbeiten zu bringen. Die systemd Leute sollten wirklich erkennen, dass sie zwei verschiedene Dinge sind.

In Ihrer Anmeldesitzung wird etwas ignoriert SIGTERModer es dauert lange, bis es beendet wird, sobald es erkannt wurde SIGTERM. Ironischerweise ist Ersteres das langjährige Verhalten einiger Job-Control-Shells. Der richtige Weg Anmeldesitzung Führer zu beenden , wenn sie diese speziellen Job-Kontrollschalen ist , ihnen zu sagen , dass die Sitzung wurde aufgehängt , worauf sie alle beenden ihre Arbeitsplätze (eine andere Art von Arbeit an den internen systemd Job) und dann kündigen sich.

Was tatsächlich passiert, ist, dass systemd auf das Stopp-Timeout des Geräts wartet, bis es darauf zurückgreift SIGKILL. Diese Zeitüberschreitung ist natürlich pro Einheit konfigurierbar und kann so eingestellt werden, dass keine Zeitüberschreitung auftritt. Daher kann man möglicherweise unterschiedliche Verhaltensweisen erkennen.

Weitere Lektüre

• Lennart Pöttering (2015). systemd . systemd manpages. Freedesktop.org.
• Jonathan de Boyne Pollard (01.06.2016). systemd bricht Hintergrundprozesse ab, nachdem sich der Benutzer abgemeldet hat . 825394. Debian-Bugtracker.
• Lennart Pöttering (2015). systemd.kill . systemd manpages. Freedesktop.org.
• Lennart Pöttering (2015). systemd.service . systemd manpages. Freedesktop.org.
• Warum ignoriert bash SIGTERM?
• https://superuser.com/questions/1102242/

Diese Meldungen stammen von systemd, einem Init-System, das Jobs startet und stoppt. Jobs können Daemons sein, aber auch kleine Aufgaben wie das Ein- und Aushängen von Festplatten, das Löschen von / tmp oder das Speichern und Wiederherstellen der Bildschirmhelligkeit während des Startvorgangs. systemctl list-unitsgibt Ihnen die Idee. Systemd verwendet "unit" und "job", um fast dasselbe zu bedeuten.

Wenn ein Job gestoppt wird, wie bei systemctl stop ..., lautet die Frage, wie lange auf den Abschluss des Jobs gewartet werden muss, bevor ein Fehler gemeldet und die Prozesse des Jobs mit dem SIGKILLSignal beendet werden. Wir wollen wirklich nicht verwenden, es SIGKILLsei denn, wir müssen, da es nicht die Möglichkeit gibt, dass der Prozess sauber beendet wird. Bei einigen Prozessen kann es sein, dass einige Sekunden ausreichend Zeit sind, um einen Fehler zu deklarieren. Bei anderen Prozessen, z. B. einer Datenbank, sind möglicherweise umfangreiche Netzwerk- und Festplatten-E / A-Vorgänge erforderlich, damit der Job ordnungsgemäß beendet werden kann. Daher können diese Einheiten einige Minuten zum ordnungsgemäßen Herunterfahren verwendet werden .

Was Sie beim Herunterfahren sehen, ist das Äquivalent systemctl stop $UNIT_NAMEdessen, dass die Ausführung einige Zeit in Anspruch nimmt. Es gibt einen Zähler, der die abgelaufenen Sekunden und die maximale Wartezeit bis zur Ausgabe von SIGKILL anzeigt und das Herunterfahren unabhängig davon abläuft.

Sofern keine guten Gründe für eine lange Verzögerung sprechen, deutet dies in der Regel auf eine Fehlfunktion hin. Dies kann daran liegen, dass ein DHCP-Server nicht auf ein Release reagiert und die Release-Aktion daher eine Zeitüberschreitung aufweisen muss oder dass ein Fehler auftritt, der dazu führt, dass ein Dämon nie beendet wird.

Ein Dienst steckt fest und systemd wartet darauf, dass er beendet wird. Systemd schätzt wahrscheinlich nicht genau, wie lange es dauern wird. Die Zeit (normalerweise 90 Sekunden) gibt an, wie lange systemd warten wird, bis die Geduld aufgebraucht ist. Siehe diesen Beitrag:

Für die Sitzung c2 des Benutzers wird ein Stoppjob ausgeführt

"Jobs stoppen" ist, wenn darauf systemdgewartet wird, dass ein bestimmter "Job" gestoppt wird, z. B. ein Prozess, auf dessen Abschluss gewartet wird, bevor er fortgesetzt wird. Wenn eine Warnmeldung angezeigt wird, dass ein Stoppjob ausgeführt wird (usw.), bedeutet dies technisch, dass in der Jobwarteschlange etwas ansteht.

Beachten Sie jedoch vor dem Durchsuchen der gesamten Systemjobwarteschlange, dass diese Warnmeldungen manchmal ein indirektes Ergebnis von Umgebungsfaktoren sind (in der Tat wird die Nachricht in ihrem GitHub-Repo sogar als möglicher Fehler bezeichnet).

Zum Beispiel: Wir bekamen Meldungen zum Thema "Job beenden" und konnten nicht herausfinden, warum ... sich herausstellte, dass auf der Festplatte fast kein Speicherplatz mehr vorhanden war und das Betriebssystem sich merkwürdig verhält.

Upgrade des Servers auf eine größere Festplatte und Neustart behoben;)