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 » 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