Es gab jetzt ab und an Tage, an denen mich mein ThinkPad X1 2-in-1 Gen 10 (per Thunderbolt 3 am externen Monitor hängend) morgens nicht wie erwartet mit einem blinkenden, sondern einem dauerhaft leuchtenden „i“ begrüßte. Das Notebook war also in der Nacht nicht wie gewünscht automatisch in den Standby bzw. Suspend-Modus gewechselt. Die manuelle Betätigung des Suspend-Buttons im Top-Panel blieb folgenlos.
Da die Ausgaben der Befehle
sudo journalctl
sudo dmesg -wkeine offensichtliche Fehlerquelle aufzeigten, folgte der Versuch, den Suspend per Console anzustoßen:
systemctl suspendDamit gab es eine erste Meldung über die Fehlerquelle:
Operation inhibited by "USERNAME" (PID 3003 "gnome-session-s", user USERNAME), reason is "user session inhibited".
Please retry operation after closing inhibitors and logging out other users.
'systemd-inhibit' can be used to list active inhibitors.
Alternatively, ignore inhibitors and users with 'systemctl suspend -i'.Der Prozess mit der ID 3003 – der „gnome-session-service“ verhinderte also den Wechsel in den Suspend-Modus. Viel mehr Infos brachte auch
systemd-inhibitnicht, außer dass der Prozess auch den Shutdown verhindern würde.
WHO USERNAME
UID 1000
USER USERNAME
PID 3003
COMM gnome-session-s
WHAT shutdown:sleep WHY user session inhibited MODE blockWas hier das Problem war, hätte ich daher auch herausgefunden, wenn ich manuell versucht hätte, das Notebook herunterzufahren. Dann wäre nämlich ein GNOME-Dialog erschienen, der gesagt hätte, dass ein Herunterfahren aufgrund nicht abgeschlossener Kopiervorgänge nicht möglich ist (um diese dann nach kurzer Zeit abzuschließen und herunterzufahren)
Zu der gleichen Erkenntnis brachte mich aber auch
gnome-session-inhibit --listmit der sehr eindeutigen Rückmeldung,
org.gnome.Nautilus: Dateien werden kopiert (logout, suspend)Der Übeltäter war also Nautilus, auch wenn in der GUI keine laufenden Kopiervorgänge mehr angezeigt wurden, und ein halber Tag seit der letzten Kopieraktion vergangen war.
Der Inhibitor von Nautilus wurde durch das Beenden des Programms (Strg+Q) nicht direkt entfernt, sondern erst nach dem erneuten Starten von Nautilus. Anschließend funktionierte Suspend und Shutdown wieder normal.
Allerdings ist damit das grundsätzliche Problem weiterhin ungelöst: warum schließt Nautilus regelmäßig Kopiervorgänge nicht ab – oder vermutlich wahrscheinlicher: warum wird der Inhibitor regelmäßig nicht korrekt zurückgesetzt?
Die weitere Suche heute führte zu einem entsprechenden Bug-Report für Nautilus, der mittlerweile an Gnome-Session übergeben wurde, aber bislang noch offen ist (auch bei anderen Programme scheint es ab und an zu dem gleichen Problem zu kommen, etwa durch vermeintlich nicht abgeschlossene Downloads bei Chrome oder noch laufende Videos bei Firefox).