[solved] systemd, 90s hang on shutdown, Jessie

[ingo2]

Es gab ja hier schon mal einen Thread mit großer Diskussion um systemd und die doch recht verbreiteten shutdown-Probleme. Damals habe ich dann einen Tipp und Würgeround im Zusammenhang mit NFS bekommen:
viewtopic.php?f=15&t=158291&hilit=umoun ... 5#p1082753
Das hat zwar deutlich Bessrung gebraht, aber das Problem nicht endgültig gelöst.

Jetzt habe ich durch Zufall eine weitere Beobachtung gemacht:
An meinem PC hängt ein über USB angeschlossener Drucker (DeskJet 970cxi). Der ist auch für die Laptops im localen Netzwerk freigegeben und das wird auch genutzt. Bisher hatte ich den Drucker immer ausgeschaltet, wenn keine Aufträge mehr zu erwarten waren. Das ist ein "soft-off" und der Status übersteht auch Power-on/off. In letzter Zeit war ich einfach faul und habe den Drucker nicht mehr separat (soft) ausgeschaltet, sondern immer zusammen mit dem PC einfach ein- und aus-geschaltet (Mehrfach-Steckdose) und das "soft-off" nicht mehr benutzt.

Und siehe da, die Hänger von systemd beim Shutdown waren praktisch verschwunden.

Bin dann der Sache auf den Grund gegangen und habe diesen Bug-Report gefunden: https://bugs.debian.org/cgi-bin/bugrepo ... bug=759348. Ist wohl ein bisher ungefixter Bug in cups-browsed. Darin findet man auch diesen Rat:

Stop cups-browsed before shutdown or add "TimeoutStopSec=5" to /etc/systemd/system/multi-user.target.wants/cups-browsed.service reduce the hang to exactly 5 seconds.

Allein das Stoppen von cups-browsed hat bei mir nicht ausgereicht, aber zusätzlich auch cupsd vor dem Shutdown stoppen, hat's dann gebracht.

Damit sehen meine "Helper" für Shutdown und Reboot auf dem XFCE-Desktop so aus:

Code: Alles auswählen

/bin/bash -c "sudo /etc/init.d/umountnfs.sh && sudo systemctl stop cups-browsed.service cups.service && xfce4-session-logout --reboot"

/bin/bash -c "sudo /etc/init.d/umountnfs.sh && sudo systemctl stop cups-browsed.service cups.service && xfce4-session-logout --halt"

Natürlich muß man noch sudo in der /etc/sudoers anpassen und auch systemctl ohne Password zulassen.

Wäre schön, Rückmeldung zu bekommen, ob das auch bei anderen Usern hilft - denn ich bin ja nicht alleine mit dem systend-Problem und einen Drucker und damit cups hat wohl jeder.

[ingo2]

So, noch ein kurzes Update:

mit diesem Workaround (cups vorm Shutdown/Reboot separat beenden) ist für mich das Problem endgültig gelöst. Habe seitdem schon -zig Reboots getestet - ohne Probleme. Es gibt höchstens ab und zu mal ein Delay von 2-3 sec., das sind meiner Erfahrung nach die Fälle, in denen sonst der 90s Timeout gelaufen ist.

Setze den Thread deshalb auf [solved].

[scientific]

Hmmm...

Sollte nicht auch ein

Code: Alles auswählen

Conflicts=cups-browsed.service cups.service

in einem Dropin-File in /etc/systemd/system/shutdown.target.d/cups.conf und /etc/systemd/system/reboot.target.d/cups.conf reichen?

Dann sparst du dir die ganze sudo-Geschichte und drehst einfach deinen Rechner mit dem Runterfahren oder Reboot-Button ab.

lg scientific

[ingo2]

Danke für die Antwort.
Das hört sich eigentlich ja gut an, ist nur die Frage, ob das auch in der korrekten/gewünschten Reihenfolge abläuft. Die Doku von FreeDesktop sagt dazu:

Conflicts=

A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies.

If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not the required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.

Da sicherlich das Stoppen von CUPS Teil des shutdown-Prozesses von systemd ist, frage ich mich: wer gewinnt | ist schneller?
Wenn ich das dagegen in einem bash-script vor dem shutdown ausführe, ist gewährleistet, das wirklich CUPS beendet ist bevor der shutdown eingeleitet wird.

Ach noch eine zusätzliche Beobachtung, die aber schon älter ist, hier jedoch paßt:
Damals hat das Purgen von AVAHI auch eine deutliche Verbesserung des Shutdown's (90s timeout) gebracht

Gruß Ingo

[TomL]

BTW, Deine ganze Konstruktion ist sowieso nur noch vorübergehend verwendbar.... spätestens mit dem Wechsel nach Stretch wirst Du eine neue Lösung suchen müssen... weil Stretch die von dir verwendete umountnsf in /etc/init.d gar nicht mehr hat. Ich habe das allerdings damals schon gesagt, das Problem hat seine Ursache definitiv nicht im Shutdown, sondern eindeutig im "unklaren" Boot-Vorgang. Wird die Bootphase richtig eingestellt, gibt es m.M.n. automatisch keine Probleme mit dem Shutdown.

Nachtrag
Sorry... hab da zuerst was falsch verstanden und bin deswegen zu einem falschen Schluss gekommen.... deshalb habe ich den ersten Absatz jetzt nachträglich entfernt....

[ingo2]

Ok, dann behalte ich erst mal meinen Würgeround bei.
Der wahre Hund liegt meiner Vermutung nach in irgendwelchen Netzwerk-Funktionen von ifupdown, die seit Jessie nicht mehr 100% sauber mit allen Diensten zusammenarbeiten (oder eher umgekehrt)- aber das ist nur "Gefühl", belegen kann ich das nicht.

BTW, Deine ganze Konstruktion ist sowieso nur noch vorübergehend verwendbar.... spätestens mit dem Wechsel nach Stretch wirst Du eine neue Lösung suchen müssen... weil Stretch die von dir verwendete umountnsf in /etc/init.d gar nicht mehr hat. Ich habe das allerdings damals schon gesagt, das Problem hat seine Ursache definitiv nicht im Shutdown, sondern eindeutig im "unklaren" Boot-Vorgang. Wird die Bootphase richtig eingestellt, gibt es m.M.n. automatisch keine Probleme mit dem Shutdown.

Ja, habe hier nebenbei auch noch ein Stretch für Versuche - da gibt's das Problem praktisch nicht. Wegen dieser ganz großen Umbau-Aktion mit Systend in Jessie werde ich Stretch sowieso frisch installieren, sobald das erste Point-Release davon raus ist - also Herbst. Das momentane Jessie ist schon ein Upgrade aus Wheezy.

EDIT:
Nachtrag: Mein oben erwähntes Test-Stretch ist ein Upgrade aus dem aktuellen Jessie (ex Wheezy). Da beobachte ich beim Shutdown, daß es manchmal bis zu 9sec. dauert, bis die beiden Netzwerk-Interfaces "down" sind (statt der 90s in Jessie). Das wird aber ganz sauber auch auf der Konsole angezeigt. 1 Interface ist eth0, daran hängt derNetzwerk-Anschluß, das 2te Interface ist eine WLAN-Karte (Intel), die ich nur per "ifup" initialisiere, aber nich weiter konfiguriere. Die nutze ich nur für WLAN-Scans, um so zu sehen, was es hier in der Nachbarschaft so gibt: ca. 20 SSID's auf 2,4GHz

[scientific]

Probier und setz noch ein Before=shutdown.target reboot.target rein und teste.

Lg scientific

[scientific]

Wenn das nãmlich klappt, bist du WM/DE-unabhängig.

[scientific]

Zum Thema Conflicts=
Wenn shutdown.target gestartet wird, läuft cupsd.service bereits - und wird demgemäß beendet. Problematisch wärs ja wenn beide gleichzeitig GESTARTET würden.

Aber die Geschichte mit dem unklaren Bootvorgang klingt auch gut.

[ingo2]

Erst mal Danke für die Vorschläge, das sauber zu lösen.

Im Moment bin ich wirklich zufrieden mit meinem "Hack". Jessie fährt jetzt seit Wochen immer problemlos in ein paar Sekunden runter. Habe das täglich mehrmals getestet - ohne einen einzigen Hänger. Für mich ist das eine zuverlässig funktionierende Lösung.

Auf der gleichen Hardware habe ich auch Stretch (ex Jessie, ex Wheezy) laufen, aber ohne diesen Hack. Stretch, bzw. dessen Systemd ist da offenbar intelligenter:
Was dort manchmal statt des 90s-Timeouts passiert:
Ein delay von ca. 9 sec. und währenddessen auf der Konsole eine Warnmeldung mit Sekundenzähler dieser Art:

Code: Alles auswählen

.. a stop job ios running for ifup interface wlan0 ...

(früher lautete die Meldung mal so was wie "deconfiguring interface wlan0" oder so ahnlich.
Da macht sich offenbar irgendeine Anwendung am Interface wlan0 zu schaffen, die da garnichts zu suchen hat. Wie oben schon geschrieben, ich bringe das WLAN Interface nur up, damit ich mal damit scannen kann - es ist nicht konfiguriert!

Eventuell ist das besagtes "cups" oder "cups-browsing"?.
Ich will aber nicht versuchsweise die WLAN-Karte ausbauen, brauche sie ab und zu mal, habe damit auch schon hostapd betrieben. Aber das ist alles deaktiviert/deinstalliert. Das Interface sollte niemanden etwas angehen, ich fahre es auch korrekt mit ifdown in der interfaces wieder runter - was normalerweise ganz fix und ohne Delay geht.

[scientific]

Kann man cups-browsed nicht beibringen, nicht auf wlan0 zu lauschen?