☰

Ordentliches Herunterfahren mit Suspend-Job, der im Systemaufruf hängt

tag-icon • tag-icon linux kernel io suspend freeze
Ordentliches Herunterfahren mit Suspend-Job, der im Systemaufruf hängt

Als ich das System gestern angehalten habe, wurde der Job nicht beendet und systemd-suspend.serviceseitdem hängt ein Job im ununterbrochenen Ruhezustand:

# systemctl list-jobs
  JOB UNIT                    TYPE  STATE  
21595 post-resume.target      start waiting
21593 systemd-suspend.service start running
21592 suspend.target          start waiting
21596 post-resume.service     start waiting

# systemctl status systemd-suspend.service
● systemd-suspend.service - Suspend
   Loaded: loaded (/nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/example/systemd/system/systemd-suspend.se>
   Active: activating (start) since Sat 2020-04-04 03:07:36 CEST; 23h ago
     Docs: man:systemd-suspend.service(8)
 Main PID: 16761 (systemd-sleep)
       IP: 0B in, 0B out
    Tasks: 1 (limit: 4915)
   Memory: 1.0M
      CPU: 20ms
   CGroup: /system.slice/systemd-suspend.service
           └─16761 /nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/lib/systemd/systemd-sleep suspend

Apr 04 03:07:36 phlegethon systemd[1]: Starting Suspend...
Apr 04 03:07:36 phlegethon systemd-sleep[16761]: Suspending system...

# ps aux |grep suspend
root     16761  0.0  0.0  10364  2052 ?        Ds   Apr04   0:00 /nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/lib/systemd/systemd-sleep suspend

Wenn ich versuche, den Suspend manuell auszulösen, antwortet der Kernel (5.4.14) mit EBUSY:

# echo mem >/sys/power/state
-bash: echo: write error: Device or resource busy

Es sieht so aus, als ob der Kernel bei der Synchronisierung einer der Festplatten hängen bleibt:

# cat /proc/16761/stack
[<0>] iterate_bdevs+0x98/0x142
[<0>] ksys_sync+0x6e/0xb0
[<0>] ksys_sync_helper+0x13/0x90
[<0>] pm_suspend.cold.8+0x213/0x361
[<0>] state_store+0x80/0xe0
[<0>] kernfs_fop_write+0xc1/0x1a0
[<0>] vfs_write+0xa5/0x1a0
[<0>] ksys_write+0x59/0xd0
[<0>] do_syscall_64+0x4e/0x120
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

In diesem Zustand gelingt es mir anscheinend nicht einmal, die Maschine normal auszuschalten:

# systemctl poweroff
Failed to power off system via logind: There's already a shutdown or sleep operation in progress

Was soll ich also tun? Ich bin versucht, zur großen Kanone (Sysrq) zu greifen, frage mich aber, ob das wirklich funktioniert? sync(1)Wie erwartet hängt es einfach, also zögere ich, es zu versuchen.

Gibt es auch eine Möglichkeit, herauszufinden,welcheFestplattengerät, auf das der Kernel wartet? Ich hoffe irgendwie, dass es nur irgendein USB-Gerät ist, nichts Ernstes.

Antwort1

Ich weiß, das beantwortet die Frage nicht direkt, aber vielleicht hilft es
Ihnen oder jemand anderem, der das hier liest, ein wenig.

Ich hatte (oder habe immer noch) ein ähnliches Problem. Suspend wurde nicht vollständig zum System zurückgeführt, da der Job hängen blieb.

24913 systemd-suspend.service start running
24912 suspend.target          start waiting

Beim Versuch, fortzufahren, habe ich die gleiche Meldung erhalten wie Sie.

# systemctl suspend
Failed to suspend system via logind: There's already a shutdown or sleep operation in progress


Mein Ziel war das Anhalten, nicht das Herunterfahren. Folgendes habe ich getan.

# systemctl cancel
# systemctl stop systemd-suspend.service

Erstens, um den hängenden Vorgang zu stoppen.
Zweitens, um das System sofort zum Anhalten zu bringen.

Nach dem Abbrechen habe ich versucht, das System in den Ruhezustand zu versetzen, systemctl suspendaber das Ergebnis war, dass wieder das gleiche Problem auftrat.
Nach dem Aufwachen habe ich den Dienst gestartet, der das System erneut in den Ruhezustand versetzt hat.

Hoffentlich kann ich jetzt ohne diesen Workaround anhalten.

Antwort2

Ich bin auf ähnliche Probleme gestoßen. Ich habe mehr als einen Tag damit verbracht, die Grundursache in meinem Fall zu finden. Glücklicherweise war dies eine nur wenige Wochen alte Installation von Ubuntu 20.04, sodass es fast einer Neuinstallation gleichkam.

Bei mir lief der NetworkManager nicht oder wurde nicht neu gestartet oder ähnliches, nachdem ich mich beim Display-Manager angemeldet hatte (unverändert gegenüber der Standardeinstellung), sodass ich keinen WLAN-Zugriff hatte.

Ich habe auch das Äquivalent des oben genannten gesehen:

# systemctl list-jobs
  JOB UNIT                    TYPE  STATE  
21593 systemd-suspend.service start running

Durch die Verwendung dieses Tools systemctl cancel 21593wird der Job gestoppt und das Problem umgangen, was zeigt, dass dies tatsächlich das Problem ist.

Von man systemd-sleepgefunden

Unmittelbar vor dem Eintreten des Systemsuspend- und/oder Ruhezustands führt systemd-suspend.service (und die anderen erwähnten Einheiten) alle ausführbaren Dateien in /lib/systemd/system-sleep/ aus. Alle ausführbaren Dateien in diesem Verzeichnis werden parallel ausgeführt und die Ausführung der Aktion wird erst fortgesetzt, wenn alle ausführbaren Dateien fertig sind.

Als ich es untersuchte, /lib/systemd/system-sleepstellte ich fest, dass es Skripte enthielt, tlpdie ich erst kürzlich installiert hatte. Ich deinstallierte tlp und die zugehörigen Pakete mit

sudo apt --purge remove tlp tlpui tlp-rdw

Und das Problem verschwand vollständig.

verwandte Informationen