shutdown-errors

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
TomL

Re: shutdown-errors

Beitrag von TomL » 27.05.2017 19:06:53

Poste doch mal die journalausgabe nach nopaste. NICHT komplett, sondern ab dem Timestamp, wo du

Code: Alles auswählen

systemctl poweroff 
abgesetzt hast.

Und dann, nach Neustart:

Code: Alles auswählen

journalctl -b -1 >~/log 
Vielleicht kann man was erkennen.

Und auch

Code: Alles auswählen

journalctl -b -p err 

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: shutdown-errors

Beitrag von scientific » 27.05.2017 20:52:34

Code: Alles auswählen

systemctl enable --now debug-shell
Damit bekommst du eine Debug-shell auf ALT+STRG+F9

Damit kannst du auch hängengebliebe Shutdowns analysieren.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 28.05.2017 13:49:29

TomL hat geschrieben:Poste doch mal die journalausgabe nach nopaste.
Das war insofern schon mal hilfreich, als dass ich bislang nicht wusste, wie man an diese Informationen ran kommt. Ich musste die persistente Speicherung noch einschalten, aber das habe ich im Netz gefunden, wie das geht.
Und dann, nach Neustart:

Code: Alles auswählen

journalctl -b -1 >~/log 
Ich hab' die Ausgabe mal auf das beschränkt, was meines Erachtens relevant ist:

Code: Alles auswählen

Mai 28 13:28:17 croco systemd-logind[515]: System is powering down.
[...]
Mai 28 13:28:17 croco systemd[1]: Stopping User Manager for UID 1000...
[...]
Mai 28 13:28:17 croco systemd[1]: Stopping X-Window Display Manager...
[...]
Mai 28 13:28:17 croco systemd[1]: Failed to propagate agent release message: Transport endpoint is not connected
[dieser Eintrag 13 mal)
[...]
Mai 28 13:28:20 croco systemd[1]: Stopped MariaDB database server.
Mai 28 13:29:47 croco systemd[1]: xdm.service: State 'stop-sigterm' timed out. Killing.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Killing process 592 (xdm) with signal SIGKILL.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Killing process 613 (Xorg) with signal SIGKILL.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Killing process 1100 (Xorg) with signal SIGKILL.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Killing process 1112 (Xorg) with signal SIGKILL.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Main process exited, code=killed, status=9/KILL
Mai 28 13:29:47 croco systemd[1]: Stopped X-Window Display Manager.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Unit entered failed state.
Mai 28 13:29:47 croco systemd[1]: xdm.service: Failed with result 'timeout'.
[...]
Mai 28 13:29:49 croco systemd[1]: Starting Power-Off...
Mai 28 13:29:49 croco systemd[1]: Shutting down.
Mai 28 13:29:49 croco lvm[1876]:   2 logical volume(s) in volume group "croco-vg" unmonitored
Mai 28 13:29:49 croco kernel: systemd-shutdow: 43 output lines suppressed due to ratelimiting
Mai 28 13:29:49 croco systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mai 28 13:29:49 croco lvmetad[259]: Failed to accept connection errno 11.
Mai 28 13:29:49 croco systemd-journald[1662]: Journal stopped
Der shutdown ging diesmal nach ca. 2 Minuten durch und laut logs hängts am xdm; erst nach dem timeout ging der shutdown dann weiter.

Die vorletzte Zeile irritiert mich etwas. Muss man da was tun?

Code: Alles auswählen

journalctl -b -p err 

Code: Alles auswählen

-- Logs begin at Sun 2017-05-28 13:23:10 CEST, end at Sun 2017-05-28 13:48:28 CEST. --
Mai 28 13:30:20 croco kernel: ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160831/dswload-210)
Mai 28 13:30:20 croco kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160831/psobject-227)
Mai 28 13:30:20 croco kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20160831/tbxfload-228)
Mai 28 13:30:20 croco kernel: ACPI Error: 1 table load failures, 5 successful (20160831/tbxfload-246)
Mai 28 13:30:20 croco kernel: bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_config.bin (-2)
Mai 28 13:30:20 croco kernel: Bluetooth: hci0: Failed to load rtl_bt/rtl8821a_config.bin
Bluetooth brauche ich nicht, deswegen habe ich die Firmware nicht installiert.

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 28.05.2017 15:22:04

Im Internet bin ich bei einem ähnlichen Problem auf folgende Lösung gekommen:
Add KillMode=none to the service file.
Jetzt muss ich das also in die XDM-Service-Datei schreiben. Nur, wo finde ich die? Kann mir das jemand sagen?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von rendegast » 28.05.2017 16:24:06

Code: Alles auswählen

dpkg-query -L xdm  |  sort  |  grep systemd
Vorlage
/lib/systemd/system/xdm.service
nach /etc/systemd/system/ kopieren und wunschgemäß ändern.
Abschließend

Code: Alles auswählen

systemctl daemon-reload

Code: Alles auswählen

systemctl cat xdm.service
zeigt dann, daß die neue service-Datei benutzt wird.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: shutdown-errors

Beitrag von scientific » 28.05.2017 19:16:42

Mach es mit einem DropIn.
Eine datei /etc/systemd/system/xdm.service.d/killmode.config incl. dem Verzeichnis anlegen und folgenden Inhalt:

Code: Alles auswählen

 
[Service] 
KillMode=none

Das ergãnzt ein bestehendes Service-File.
Dann musst du nicht das original kopieren.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: shutdown-errors

Beitrag von TomL » 28.05.2017 21:17:11

berni42 hat geschrieben:

Code: Alles auswählen

Mai 28 13:28:20 croco systemd[1]: Stopped MariaDB database server.
Mai 28 13:29:47 croco systemd[1]: xdm.service: State 'stop-sigterm' timed out. Killing.
Der shutdown ging diesmal nach ca. 2 Minuten durch und laut logs hängts am xdm; erst nach dem timeout ging der shutdown dann weiter.
Nein, nicht xdm stört, damit ist alles ok, sondern die MariaDB hängt für gut 90 Sekunden. Achte mal auf die Zeiten, wie lange systemd braucht, die DB zu beenden.. also wann es danach weiter geht.

Jetzt musst Du feststellen, wie die MariaDB gestartert wird. Enweder über ein Script in /etc/init.d oder über eine Service.Unit. Wenn die DB über eine Initscript gestartet wird, ist das die Ursache.... weil systemd quasi im Schätzmode eine Standard-Unit generiert. Das heisst, die müsste man herausfinden und ändern und passend in den Start einbinden, eben mit dem Ziel, dass sie auch beim Shtudown passend berücksichtigt wird.

Schau mal nach, ob in /etc/init.d ein Initscript steht oder besser, suche mal nach der generierten Unit:

Code: Alles auswählen

systemctl -l | grep maria -i
Und wenn eine gefunden wird, poste mal den Inhalt

Code: Alles auswählen

systemctl cat gefundenerunitname.service
Dann kriegen wir das hin, dass die nicht mehr blockt.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: shutdown-errors

Beitrag von scientific » 28.05.2017 21:22:45

Systemd baut nicht im Schätzmodus irgend eine Unit, sondern anhand der im Skript definierten Abhängigkeiten eine, die das initv-Startskript aufruft. Die generierte Unit macht also kaum etwas anderes als invoke-rc.d service start.

Am Handy sind codetags hier leider unleserlich, daher kann ich zu deinem Log noch nix sagen.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 28.05.2017 21:43:18

TomL hat geschrieben:
berni42 hat geschrieben:Nein, nicht xdm stört, damit ist alles ok, sondern die MariaDB hängt für gut 90 Sekunden. Achte mal auf die Zeiten, wie lange systemd braucht, die DB zu beenden.. also wann es danach weiter geht.
Aus zweierlei Gründen denke ich, dass MariaDB nicht die Ursache ist: Zum einen: Da steht "stopped" und nicht "stopping". Den Eintrag mit "stopping" hatte ich oben rausgeschnitten, aber diesmal waren es gerade 2 Sekunden zwischen "stopping" und "stopped". Der andere Grund ist, dass er ja manchmal anzeigt, dass er auf den XDM wartet.

Ich werde aber gleich mal die MariaDB vor dem Shutdown abschalten und schauen, ob es dann geht; vielleicht hast du ja doch recht...

PS: Mit dem Kill-Befehl hat im ersten Versuch dazu geführt, dass in den Logs der xdm gar nicht mehr auftaucht, laut log der Shutdown auch nach 5 Sekunden abgeschlossen war, de fakto aber erst nach etwa 2 Minuten...

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 28.05.2017 22:03:21

Wi erwartet: Wenn ich MariaDB vorher beende, ändert sich nichts, es dauert immernoch ca. 2 Minuten und in den Logs sind nur die ersten ca. 7 Sekunden vermerkt.

Ich habe auch mal versucht, die Debug-Console zu starten, aber das hat bei mir nicht geklappt. Liegt vielleicht daran, dass bei mir Alt-Strg-F9 schon durch den XDM belegt ist. Ich werde morgen mal weitere Tests machen.

TomL

Re: shutdown-errors

Beitrag von TomL » 28.05.2017 22:32:56

scientific hat geschrieben:Systemd baut nicht im Schätzmodus irgend eine Unit
Ja, entschuldige, Du hast Recht.. die Runlevels 2, 3 und 4 einfach pauschal an multi-user.target zu binden ist kein schätzen, sondern faktisch noch weniger "flexibel passend", als wäre es geschätzt und vielleicht zufällig passend. Fakt ist, das was raus kommt, ist Schrott beim Blick auf die von systemd mögliche Präzison durch die verfügbaren Targets.

Jedenfalls empfinde ich dieses sinnlose Diskutieren über solche Spitzfindigkeiten einfach nur noch nervend... genau wie dieser sinnlose Korrektur, dass Jessie anscheinend doch den I7 kann....aber mit dem BPO-Kernel ist es eben kein Jessie Stable mehr, sondern was anderes und Jessie Stable kanns trotzdem nicht.

Kein Bock mehr....

@Bernie, sorry, da bin ich in die Falle getappt.... aber leíder dadurch, weil das Log fragmentiert war. Mit beiden Zeilen, also "stopping" und "stopped", wäre ich wohl nicht auf diese Falschbeurteilung gekommen. Zu xdm habe ich allerdings keinen Rat.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: shutdown-errors

Beitrag von scientific » 28.05.2017 23:04:23

Najo... Bei Debian unterscheiden sich die Runlevel aber in der Standardconfig auch kaum bis nicht... Bei SuSE war das definitiv ganz anders (hab damals 10.3 installiert gehabt)

Btw... Wenn der shutdown hängt, wechsle in die debug-shell (alt+strg+f9) und führe

Code: Alles auswählen

 systemctl list-jobs
aus.
Der Job wo running dabei steht, ist jener, auf den alle anderen warten.

Dann kannst du den service mit systemctl status servicename oder journalctl -u servicename und den üblichen Verdächtigen wie top, iotop, atop, ps und sonstigen Debug-Werkzeugen auf den Grund gehen, warum der nicht fertig wird.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von rendegast » 29.05.2017 07:04:39

Auf der Konsole läßt sich xdm.service aber schnell beenden?

Code: Alles auswählen

systemctl stop xdm.service
xdm ist so ziemlich der generischste Display-Manager,
vielleicht eher ein Bildschirmschoner oder Benutzer-Dienst/-Applet das Problem?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 29.05.2017 11:57:28

So, ich habe die debug-shell zum Laufen bekommen. Wenige Sekunden nach dem Start des Shutdown konnte ich sie aber nicht mehr benutzen, sie hat auf nichts mehr reagiert.

Das Log habe ich diesmal vollständig nach Pastebin kopiert. Auch das endet nach 4 Sekunden. Der Shutdown allerdings erst viel später.

Und noch was, was mir aufgefallen ist: Wenn ich als root mit "systemctl poweroff" beende, dann geht der Rechner nach den 2 Minuten auch aus. Wenn ich hingegen als Benutzer "halt" eingebe, dann hängt der Rechner ewig.

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 29.05.2017 12:15:57

Ich konnte nun folgendes mehrfach reproduzieren:

/etc/X11/xdm/Xservers:

Code: Alles auswählen

:0 local /usr/bin/X :0 vt7 -nolisten tcp
#:1 local /usr/bin/X :1 vt8 -nolisten tcp
#:2 local /usr/bin/X :2 vt9 -nolisten tcp
#:3 local /usr/bin/X :3 vt10 -nolisten tcp
Wenn ich vt8 bis vt10 einkommentiere, tritt das Problem auf, sonst nicht. (Ich nutze die Server, um mit unterschiedlichen Accounts eingeloggt zu sein, dann kann ich einfacher wechseln.)

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 03.06.2017 16:44:18

Nach zahlreichen Shutdowns mit unterschiedlichsten xdm-Konfigurationen kann ich nun folgendes berichten: Wenn mehr als zwei lokale X-Displays via /etc/X11/xdm/Xservers aktiviert werden, tritt das merkwürdige Phänomen auf, dass der Rechner noch 90 Sekunden nach der Meldung "Journal stopped" hängt, bevor er sich abschaltet. Es ist unabhängig davon, auf welche F-Taste ich die lokalen X-Displays setze, einzig und allein die Anzahl ist entscheidend.

Die Frage ist nun für mich, wie weitermachen. Ich denke, hier ist der falsche Ort, weil möglicherweise xdm-Spezialisten nicht mitlesen. Deswegen würde ich einen neuen Thread unter "Graphische Oberflächen" aufmachen. Ist das sinnvoll?

Desweiteren überlege ich, ob ich beim xdm-Packet einen Bug-Report einstellen soll. Auch da die Frage, ist das sinnvoll?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von rendegast » 04.06.2017 05:39:30

Nachgestellt testing/stretch,
'systemctl stop xdm.service' mit mehreren :X geht in einen timeout 90s.

xdm sendet im default SIGTERM/15 an die Xorg-Prozesse,
aber diese werden nicht alle direkt beendet.
Hier steckt wohl der Bug.
Jedoch startet systemd den xdm auch als 'nodaemon',
ob das mit hineinspielt?

Die verbleibenden Xorg lassen sich im htop auch nicht per SIGTERM/15 beenden, sondern benötigen SIGKILL/9.

Nach dem timeout verbleibt die xdm.pid, was den Neustart per 'systemctl start' verhindert.
In dem Fall 'rm /run/xdm.pid'.






Ideen zum walkaround

Code: Alles auswählen

DisplayManager._0.termSignal: 9
DisplayManager._1.termSignal: 9
DisplayManager._2.termSignal: 9
DisplayManager._3.termSignal: 9
resp.
DisplayManager*termSignal: 9
funktioniert nicht.

Code: Alles auswählen

PIDs="$(pgrep -f "Xorg :[123] vt")";  echo "$PIDs" |  egrep -q "[0-9]"  &&  kill -s 9 $PIDs
bei einfachem Einstz kommen Xorg wieder,
erst bei mehrmaliger (schneller) Anwendung sind die zusätzlichen gekillt und ein 'systemctl stop' funktioniert.
(Dieses undefinierte Verhalten scheint mir auch eine Bugmeldung wert.)

Spielereien mit
KillMode=mixed (15 an xdm und 9 an die Xorg) funktioniert nicht.
KillSignal=9, ich möchte aber ein sauberes Beenden des xdm (natürlich am liebsten auch der Xorg).
TimeoutStopSec=5, der bisher erfolgreichste Ansatz, nach garantiert 10 Sekunden der KILL der Xorg,
der Status des Beendens ist dann aber immer noch 'failed', xdm.pid ist noch vorhanden.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

berni42
Beiträge: 123
Registriert: 18.09.2016 17:11:46
Lizenz eigener Beiträge: MIT Lizenz

Re: shutdown-errors

Beitrag von berni42 » 04.06.2017 08:29:03

Was man als workarround machen kann, und was ich derzeit auch nutze, ist, dass man beim Login-Bildschirm Ctrl-R drückt. Das beendet den entsprechenden Xorg-Prozess. Mir ist allerdings nicht klar, was da im Hintergrund genau passiert.

Antworten