[erledigt] openSUSE Leap 15.0: 'reboot' klappt nicht

    Wenn ich auf meinem frisch aufgesetzten PC mit openSUSE Leap 15.0 als user 'root' den Befehl 'reboot' eingebe, dann fährt der PC zwar runter, aber bleibt am Ende bei "Reached target Shutdown." hängen und bootet nicht neu. Auch ein 'halt -p' führt nicht zum Ausschalten des Rechners.


    Muss man das irgendwo einstellen, damit das funktioniert?


    [edit]

    Garade sehe ich, dass er doch neu gebootet hat, aber eben nicht sofort, sondern erst nach mehreren Minuten (er stand bei "Reached target Shutdown." während ich diese Message schrieb). Worauf wartet er denn da?

    [/edit]


    Klaus

    Zitat von kls

    Worauf wartet er denn da?

    Wie sehen denn die Units für den VDR und den X-Server aus?


    Das vaapidevice bleibt z.B. gerne hängen, wenn es überraschend die Verbindung zum X-Server verliert (und dann reagiert der VDR nicht auf das SIGTERM-Signal und wird von Systemd nach dem KillTimeout mit einem SIGKILL abgeschossen) . Eine Lösung wäre Systemd zu sagen, dass der VDR von der Unit für den X-Server abhängt, eine andere Möglichkeit wäre das vaapidevice zu detachen, bevor man den reboot einleitet (svdrpsend plug vaapidevice deta).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von jrie

    Vor dem reboot ein systemctl start debug-shell absetzen. Vielleicht findest du so den Übeltäter.

    Das Einzige, was bei den Meldungen beim Runterfahren auffällt, ist "Failed unmounting /home.". /home ist bei mir via NFS vom Server gemountet, und da gibt es typischerweise Prozesse, die dort Dateien offen haben. Aber beim Runterfahren sollten doch alle Prozesse automatisch gekillt werden.

    Zum Vergleich habe ich mal den Job, der sein cwd auf /home hat vor dem Runterfahren von Hand gekillt, und da hat der Reboot reibungslos funktioniert.

    Muss man ihm das extra sagen, dass er beim Runterfahren noch laufende Prozesse killen soll?


    @seahawk1986 Zu diesem Zeitpunkt befand sich auf dem Rechner nur eine minimale Installation, ohne X-Server oder gar VDR.


    Klaus

    Zitat von kls

    Muss man ihm das extra sagen, dass er beim Runterfahren noch laufende Prozesse killen soll?

    Macht er ja, aber erst nach einem Timeout.

    Das Timeout explizit herabsetzen könnte helfen.

    Dann gibt es da noch in der fstab die x-systemd.* mount Optionen. Möglicherweise hilft eine von denen weiter. Kenne mich damit aber nicht gut genug aus. Die Frage ist, ob er unmounten kann, solange der Job noch läuft.

    Schau mal hier unter fstab, ob da was für dich passt. Wie wird denn bei dir das "/home" gemounted, über fstab?

    Ist denn gewährleistet, dass das Perl-Skript auf ein SIGTERM-Signal reagiert oder lässt sich das z.B. nur mit einem SIGINT abschießen, wie man es mit STRG+c sendet?

    Zitat von kls

    Und wo macht man das?

    Global kann man in der /etc/systemd/system.conf den Wert für DefaultTimeoutStopSec setzen (Voreinstellung sollten 90 Sekunden sein).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    /home wird über /etc/fstab gemountet:


    nfs:/home /home nfs nolock,lookupcache=none


    Das Script kann mit 'kill <pid>' abgebrochen werden, also reagiert es auf SIGTERM. Es macht auch keinerlei Anstalten irgendwelche Signal speziell abzuhandeln. Es hat auch keine Datei permanent offen, sondern lediglich als cwd ein Directory unter /home. Wenn ich in der Shell in ein Verzeichnis auf /home wechsle und dann reboot mache, klappt es es ohne weiteres (wenn das Script nicht läuft).

    Ich hänge das Script mal an, vielleicht macht es ja tatsächlich irgend etwas "komisches". Es wird alle 5 Minuten von einem cron-Job unter User 'root' aufgerufen.


    'DefaultTimeoutStopSec=3s' hat leider nichts verändert.


    Klaus


    O.T.: Gibt es eigentlich noch irgend etwas, wo sich dieser @$§!#*-systemd nicht einmischt?!

    Zitat von 9000H

    und mit grub acpi=force?


    vdr4:~ # grub acpi=force

    If 'grub' is not a typo you can use command-not-found to lookup the package that contains it, like this:

    cnf grub


    Ausserdem: was sollte ACPI damit zu tun haben, dass beim Runterfahren laufende Prozesse nicht richtig abgebrochen werden?

    Zitat von drahtjacke

    ich mounte meine nfs shares nur noch mit systemd.

    Wenn ich die Wahl habe zwischen einem Einzeiler in einer bereits bestehenden Datei (in der *alle* solchen Einträge stehen) und *elf* Zeilen in einer extra Datei, dann ist meine Wahl sehr einfach ;-).


    Klaus

    Hat leider nichts verändert.


    Hab die Option in /etc/default/grub hinzugefügt, 'grub2-mkconfig -o /boot/grub2/grub.cfg' aufgerufen und zweimal 'shutdown' gemacht (falls es erst nach einem neuen Booten gewirkt hätte). Aber beide Male musste ich einen harten Reset machen.


    Klaus

    Zitat von kls

    Ich hänge das Script mal an, vielleicht macht es ja tatsächlich irgend etwas "komisches". Es wird alle 5 Minuten von einem cron-Job unter User 'root' aufgerufen.

    Ich habe mir das gerade etwas genauer angesehen - die cron.service nutzt KillMode=process, wodurch die von Cron gestarteten Skripte (die in einer cgroup landen) nicht zusammen mit cron beendet werden (dafür bräuchte es KillMode=control-group), sondern losgelöst von dessen Abhängigkeiten weiterlaufen, bis sie sich beenden oder irgendwann im Verlauf des Shutdown-Prozess (vermutlich gegen Ende, wenn nichts anderes mehr zu tun ist) von systemd gekillt werden.


    Dann finde ich es etwas merkwürdig, das Skript regelmäßig über cron aufgerufen muss, wenn es eigentlich endlos laufen soll - für mich sieht das ein bisschen nach einem von-hinten-durch-die-Brust-ins-Auge Ansatz aus, um die mtime-Prüfung im Skript zu kompensieren, die das Skript vorzeitig beendet, wenn die Datei existiert und vor weniger als 7,2 Minuten geändert wurde.


    Aber es geht ja darum Systemd dazu zu überreden mit einem etwas eigensinnigen Skript zu kooperieren - daher würde ich das Skript statt über cron mit Hilfe einer Systemd-Unit starten lassen und die Abhängigkeiten (Netzwerk, /home gemountet) explizit angeben - für das unveränderte Skript sollte das so funktionieren, wenn man das 5-Minuten Restart-Intervall von cron beibehalten will (was nicht so ganz zu den 7,2 Minuten mtime-Alter passt, auf das das Skript prüft):

    Und die Unit dann mit systemctl enable --now eth-stats.service anschalten. Damit habe ich hier in einer openSUSE Leap 15 VM keine Verzögerung beim Shutdown.

    Zitat von kls

    O.T.: Gibt es eigentlich noch irgend etwas, wo sich dieser @$§!#*-systemd nicht einmischt?!

    Es gibt Distributionen wie Devuan (Debian-Abkömmling komplett ohne Systemd) oder Gentoo, wenn man das partout nicht haben möchte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

    Gefällt mir 1

    Das Script ist Teil meiner RRD-Tool Scripte, mit denen ich verschiedene Sachen protokolliere. Es wird von einem übergeordneten Script (via crontab) alle 5 Minuten aufgerufen, und startet, wenn "$ETH.dat" länger nicht beschrieben wurde, einen Hintergrundprozess, der alle 30 Sekunden die aktuelle Anzahl der Bytes, die über die Schnittstelle gegangen sind, in die Datei schreibt (das ist nötig, weil ansonsten der Counter überlaufen könnte). Eine "Unit" für dieses Script ist also in keinster Weise sinnvoll ;-).


    Es geht auch nicht darum, "Systemd dazu zu überreden mit einem etwas eigensinnigen Skript zu kooperieren". Systemd ist mir ehrlich gesagt schei*egal. Er soll einfach beim Runterfahren ordentlich aufräumen, so wie es früher auch der Fall war.


    "KillMode=control-group" in /etc/systemd/system/multi-user.target.wants/cron.service führt zwar dazu, dass das Script beim Runterfahren gekillt wird, aber das passiert dann natürlich auch jedesmal, wenn man cron neu startet. Damit kann man zwar leben, schön ist es aber nicht. Die Frage bleibt daher, wie man das System dazu bringen kann, beim Runterfahren *alle* Prozesse *zeitnah* zu beenden (also nicht erst nach 90 Sekunden - was, s.o., eh nicht gegriffen hat), egal wie sie gestartet wurden.

    Zitat von seahawk1986

    Es gibt Distributionen wie Devuan (Debian-Abkömmling komplett ohne Systemd) oder Gentoo, wenn man das partout nicht haben möchte.

    Wenn mich systemd weiter so ärgert werde ich das wohl irgendwann tatsächlich in Betracht ziehen müssen. Wobei Gentoo ja anscheinend auch bereits "infiziert" ist...


    Klaus

    Nachtrag: Nachdem mein alter VDR mit openSUSE Leap 42.2 diese Macke nicht hatte, habe ich mir mal dessen cron.service angeschaut, und dort kommt KillMode gar nicht vor. Nachdem ich diese Zeile auch aus der neuen cron.service entfernt habe, fährt er nun ordungsgemäß runter und ein Neustart von cron killt den Prozess nicht.

    Damit ist das Problem für mich gelöst.

    Danke für euren Input.


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden