[gelöst] A stop job is running - Bullseye / pcmanfm

[MSfree]

Ich habe meinen alten Core-i7-2600 mit Debian Bullseye und LXDE ausgestattet. Der Rechner ist ziemlich minimalistisch ausgestattet: RAM, SSD, CPU und integrierter CPU Graphik (IGP).

Ein etwas nervendes Problem tritt beim Runterfahren auf:

Im Display sieht man "a stop job is running" und eine Meldung mit einem Timeout von 1m30s. Nach 90s fährt die Kiste ordnungsgemäß runter.

Auf der Suche nach der Ursache kommt aus dem Journal:

Code: Alles auswählen

Sep 05 00:51:39 i7 systemd-logind[514]: System is powering down.
Sep 05 00:51:39 i7 polkitd(authority=local)[511]: Unregistered Authentication Agent for unix-session:2 (system bus name>
Sep 05 00:51:39 i7 udisksd[515]: udisks daemon version 2.9.1 exiting
Sep 05 00:51:39 i7 systemd[671]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 00:51:39 i7 systemd[671]: pulseaudio.service: Failed with result 'exit-code'.
Sep 05 00:53:10 i7 systemd[1]: session-2.scope: Stopping timed out. Killing.
Sep 05 00:53:10 i7 systemd[1]: session-2.scope: Killing process 749 (pcmanfm) with signal SIGKILL.
Sep 05 00:53:10 i7 systemd[1]: session-2.scope: Failed with result 'timeout'.
Sep 05 00:53:10 i7 zeitgeist-fts[818]: Error releasing name org.gnome.zeitgeist.SimpleIndexer: The connection is closed
Sep 05 00:53:10 i7 zeitgeist-fts[818]: zeitgeist-fts.vala:252: The connection is closed
Sep 05 00:53:10 i7 systemd[1]: Shutting down.

Mir sieht das danach aus, daß pulseaudio beim Beenden einen Fehler wirft und dann 90s gewartet wird, bis der endgültig gekillt wird. Oder liegt das am (bereits beendeten) pcmanfm, der da zu killen versucht wird?

[Livingston]

Sieht so aus, als würde der Haken bei pulseaudio liegen und zum anderthalbminütigen Däumchendrehen führen. Das sorgt dann dafür, dass alles, was in session-2.scope nicht sauber abgeschaltet wird, nun mit Zwangsaus (SIGKILL) gestoppt wird. Die Timestamps deuten darauf hin, dass das dann auch klappt.

Nutzt Du pcmanfm für das Einstellen des Hintergrundbildes in der X-Session? Wenn ja kannste den ja mal vor dem Runterfahren per Hand stoppen.

[detix]

Ein paar andere Möglichkeiten:
in $HOME und /root .cache und .config/pulse löschen und/oder die Wartezeiten für systemd ändern:

/etc/systemd/system.conf und /etc/systemd/user.conf:

DefaultTimeoutStartSec=20s # Timeout 90s auf 20s
DefaultTimeoutStopSec=10s # Timeout 90s auf 10s

PulseAudio wirds nicht stören...

[MSfree]

Code: Alles auswählen

DefaultTimeoutStartSec=20s # Timeout 90s auf 20s
DefaultTimeoutStopSec=10s # Timeout 90s auf 10s

Sowas hatte ich im Netz auch schon gefunden. Das ist meiner Meinung nach aber rumdoktern an Symptomen. Die Wartezeit verkürzt sich von 90s auf 10s, falsch laufen tut es aber trotzdem.

[TomL]

Das ist meiner Meinung nach aber rumdoktern an Symptomen. Die Wartezeit verkürzt sich von 90s auf 10s, falsch laufen tut es aber trotzdem.

Ich halte das auch für ein gefährliches Spiel mit dem Feuer und würde -genau wie Du sagst - nicht die Symptome verstecken, sondern die Ursachen beseitigen. Ein so kurzer Timeout teilt dem Systemmanager mit, nicht länger als 10 Sekunden zu warten, wenn er einen Prozess/ Service-Unit mit dem Exec-Stop-Statement aufgefordert hat, sich zu beenden. Wäre mit dem Stop-Statement eines beliebigen anderen Prozesses/Service-Unit als Beispiel in dessen Prozess auch noch ein Rückschreiben erforderlich, und das vielleicht auf eine zwischenzeitlich schlafende Platte, die erst mal wach werden muss, und dann vielleicht sogar noch an einer nicht-optimalen WLAN-Verbindung, hast Du fast eine Garantie für Datenverlust, weil dieser Prozess, der nix mit dem Problem zu tun hat, auch von dem (hier dann zu) kurzen Timeout betroffen ist.

Ich würde jedenfalls niemals den Timeout reduzieren, wenn ich nicht zu 100% sicher wäre, dass ich weder jetzt noch in Zukunft (wenn ich diese Änderung schon wieder vergessen habe), jemals eine Abhängigkeit einrichten werde, die davon betroffen sein kann.

[MSfree]

Wenn ich mich vom LXDE nur abmelde und dann den Shutdown vom Anmeldebildschirm (lightdm) durchführe, fährt die Kiste in einer Sekunde runter.

Was dabei auffällt, ist, daß bei einem Shutdown direkt aus LXDE heraus der Soundserver (pulseaudio) mit Fehlerstatus beendet wird, weil ihm der X-Server unter dem Hintern weggezogen wurde. Daraufhin wird mehrfach versucht, den Soundserver neu zu starten, was natürlich wegen des nicht mehr laufenden X-Servers immer wieder fehlschlägt.

Beim Logout aus LXDE wird ebenfalls der Soundserver beendet, weil aber der X-Server für den Anmeldebildschirm neu gestartet wird, gelingt hier auch der Naustart des Soundservers. Der Shutdown über den Anmeldebildschirm geht dann regulär vonstatten, der Soundserver wird normal beendet und es wird nicht gewartet.

Für mich scheint das ein Reihenfolgeproblem zu sein. Meiner Vermutung nach sollte der der Soundserver beim Abmelden durch die Benutzersession beendet werden, bevor der eigentliche Shutdownvorgang angestossen wird.

Was ebenfalls aus dem Journal ersichtlich ist, ist, daß der Soundserver beim Anmelden mehrfach gestartet wird, weil er wohl mehrfach keine Verbindung zum X-Server aufbauen kann, und sich dadurch aus dem gleichen Grunde wie beim Shutdown mit einem Fehlerstatus beendet.

[MSfree]

Ich würde jedenfalls niemals den Timeout reduzieren, wenn ich nicht zu 100% sicher wäre.

Du hast völlig recht. Auf meinem Router läuft beispielsweise squid, der zum Beenden durchaus mal einige Sekunden braucht. Da wird wohl noch einiges aus dem Memory-Cache auf den Disk-Cache gekippt.

[detix]

Wenn ich mich vom LXDE nur abmelde und dann den Shutdown vom Anmeldebildschirm (lightdm) durchführe, fährt die Kiste in einer Sekunde runter.

Auf meinem Router läuft beispielsweise squid, der zum Beenden durchaus mal einige Sekunden braucht. Da wird wohl noch einiges aus dem Memory-Cache auf den Disk-Cache gekippt.

Das passt aber jetzt nicht so ganz zusammen, oder?

systemd kümmert es im Grunde einen Schei3dreck ob da noch irgendwas anständig beendet werden muss...
ob 90s oder 10s, ich bin jedenfalls nicht bereit 90s zu warten da erfahrungsgemäß in dieser Zeitspanne eh nichts mehr passiert.

[MSfree]

Das passt aber jetzt nicht so ganz zusammen, oder?

systemd kümmert es im Grunde einen Schei3dreck ob da noch irgendwas anständig beendet werden muss...

Doch. Beim Shutdown wird erstmal jedem Daemon ein SIGHUB geschickt. Die meisten Daemons reagieren darauf mit einem geordneten Beenden ihres Prozesses. Wenn dabei noch Daten geschrieben werden müssen, wie bei squid, dann findet das während dieser Phase statt. Erst, wenn der Prozeß 90s nach dem SIGHUB noch lebt, wird er mit einem SIGKILL endgültig abgeschossen. Verkürzt man dann die Wartezeit, wie oben vorgeschlagen, kann es passieren, daß Serverdienste ihren im RAM befindlichen Datenbestand nicht mehr vollständig auf die Platte schreiben können. Bei Datenbankservern ist das also keine gute Idee.

ob 90s oder 10s, ich bin jedenfalls nicht bereit 90s zu warten da erfahrungsgemäß in dieser Zeitspanne eh nichts mehr passiert.

Wie gesagt, es gibt Serverprogramme, die zum Beenden Zeit benötigen, in diesem Fall ist warten erklärbar und ich bin dann auch bereit, diese Zeit zu akzeptieren.

Im Falle des betroffenen Core-i7 ist das alles allerdings ncht der Fall. Da laufen keine Serverdienste, die Zeit benötigen würden. Da kachelt beim Shutdown aus LXDE der Soundserver ab, was zum wiederholten Neustart des Soundserver beim Shutdown führt, was aber auch mehrfach fehlschlägt und erst nach 90s beendet wird. Die Regel in der pulseaudio.service Datei lautet

Code: Alles auswählen

Restart=on-failure

Diese Regel ist nötig, weil beim Login der Soundserver ebenfalls nicht beim ersten Mal hochkommt, zwei bis dreimal mit Ferhler aussteigt, bevor er dann doch gestartet werden kann. Auch hier ein Reihenfolgeproblem, weil der Soundserver wohl zu früh gestartet wird und nicht auf den X-Server geartet wird.

Das alles kann ich inzwischen den Journal entnehmen. Der kurze Journalauszug im ersten Post ist kein vollständiger Auszug, den hatte ich dummerweise nicht mit root-Rechten erstellt. Ein Vollständiges Log des Shutdowns ist etliche Zeilen lang und bring eigentlich nur die Erkenntnisse, die ich hier wiedergegeben habe. Wenn es interessiert, kann ich das volle Journalauszüge noch nachliefern.

Meiner Meinung nach ist das ein Reihenfolgeproblem, denn der Soundserver sollte einfach vor dem X-Server beendet werden

[TomL]

systemd kümmert es im Grunde einen Schei3dreck ob da noch irgendwas anständig beendet werden muss... ob 90s oder 10s, ich bin jedenfalls nicht bereit 90s zu warten da erfahrungsgemäß in dieser Zeitspanne eh nichts mehr passiert.

systemd informiert mit dem Anziehen (z.B.) des shutdown.target alle laufende Prozesse über den geplanten shutdown und gibt ihnen 90 Sekunden Zeit dafür, alles notwendige für ein geordnetes Ende des betroffenen Prozesses zu tun... wozu auch ein Zurückschreiben von Daten gehören kann. In besonderen Fällen, bei mir wäre das ein FTP-Server, der auf einen tmpfs-Speicher schreibt und der bei Shutdown aktive Kontroll-Dateien auf eine schlafende Platte zurückschreiben muss, dafür braucht es eben mehr als die 10 Sekunden. Auf meinem Server laufen 3 VMs, die sich ebenfalls geordnet beenden müssen und die jeweils ihren eigenen Shutdown ohne Datenverlust durchführen sollen. Zum Beispiel darf Samba auf dem Server erst dann beendet werden, wenn die VMs fertig sind, alles gesichert haben und ich im System feststellen kann, dass sie tatsächlich aus sind. Würde mein Server-systemd das nach 10 Sekunden radikal rasieren, wären meine Daten vermutlich schnell kaputt.

Die Aussage, dass nichts mehr passiert, trifft also so pauschal schlichtweg nicht zu ... weil sie völlig außer acht läßt, dass möglicherweise auch eigene Service-Units laufen, die besondere Abhängigkeiten auch beim Shutdown haben. Bei mir läuft wirklich alles 'individuelle' über eigene Service-Units....und bei einigen meiner Units passiert durchaus noch was gerade wegen dem Shutdown.

[DeletedUserReAsG]

Auch hier ein Reihenfolgeproblem, weil der Soundserver wohl zu früh gestartet wird und nicht auf den X-Server geartet wird.

Eigentlich sollte Pulse von X komplett unabhängig sein. Es sei denn, du startest ihn beim Login über etwa einen Displaymanager als User-Daemon – aber selbst dann sollte ihn nicht interessieren, was X in der Zeit macht.

Das Log im Eingangsbeitrag zeigt hingegen, dass pcmanfm nach dem Timeout gekillt wird. So richtig mag ich nicht glauben, dass Pulse damit was zu tun haben soll. Eher hätte ich so Netzwerk-FS oder sowas im Kopf. Damit hatte der Dateimanager in der Vergangenheit wohl auch schon Probleme.

[MSfree]

So, die Ursache diese Problems war pcmanfm. Ich hatte im Internet dazu schon vor Monaten einen Hinweis gefunden, und daß das Problem mit der Version 1.3.2-1 von pcmanfm behoben sei. Ich hatte dann einen Bugreport bei Debian erstellt, mit der Bitte, pcmanfm auf die genannte Version zu aktualisieren. Mit dem gestrigen dist-upgrade kam dann auch der aktualisierte pcmanfm. Shutdown und reboot gehen jetzt blitzschnell.