shutdown-errors

[TomL]

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]

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

[rendegast]

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?

[berni42]

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]

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]

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]

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.

[berni42]

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.