Laptop schaltet nach suspending einfach ab

[scientific]

Hi Leute!

Ich beobachte schon seit geraumer Zeit ein seltsames Phänomen auf meinem Laptop.
Schicke ich den Laptop mit

Code: Alles auswählen

systemctl suspend

, funktioniert das meistens.
Manchmal aber braucht er dann ewig lange bei schwarzem Bildschirm (könnte von der Zeit irgend ein Timeout aus systemd sein) und schaltet dann ab. Schalte ich ihn wieder ein, bootet er von neuem.
Sehe ich im Journal das Log des letzten Boots an, dann sind die letzten Zeilen:

Code: Alles auswählen

Okt 03 00:51:39 aldebaran NetworkManager[705]: <info>  [1506984699.4773] manager: sleep requested (sleeping: no  enabled: yes)
Okt 03 00:51:39 aldebaran NetworkManager[705]: <info>  [1506984699.4773] manager: sleeping...
Okt 03 00:51:39 aldebaran NetworkManager[705]: <info>  [1506984699.4775] device (80:7A:BF:17:2D:09): state change: disconnected -> unmanaged (reason 'sleeping') [30 10 37]
Okt 03 00:51:39 aldebaran NetworkManager[705]: <info>  [1506984699.4777] manager: NetworkManager state is now ASLEEP
Okt 03 00:51:39 aldebaran NetworkManager[705]: <info>  [1506984699.4781] device (wlo1): state change: activated -> deactivating (reason 'sleeping') [100 110 37]
Okt 03 00:51:39 aldebaran org.gnome.Shell.desktop[1159]: Window manager warning: Failed to set power save mode for output eDP-1: Keine Berechtigung
Okt 03 00:51:39 aldebaran dbus[674]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Okt 03 00:51:39 aldebaran systemd[1]: Starting Network Manager Script Dispatcher Service...
Okt 03 00:51:39 aldebaran dbus[674]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Okt 03 00:51:39 aldebaran systemd[1]: Started Network Manager Script Dispatcher Service.
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: find-scripts: Cannot execute '/etc/NetworkManager/dispatcher.d/ddclient.sh': not executable by owner.
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: req:1 'connectivity-change': new request (5 scripts)
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: req:1 'connectivity-change': start running ordered scripts...
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: find-scripts: Cannot execute '/etc/NetworkManager/dispatcher.d/pre-down.d/stop-services.sh': not executable by owner.
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: req:2 'pre-down' [wlo1]: new request (1 scripts)
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: connectivity-change
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0594 Gs  no app for changed workspaces-to-dock@passingthru67.gmail.com
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0598 Gs  no app for changed suspend-button@laserb
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0607 Gs  no app for changed openweather-extension@jenslody.de
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0615 Gs  no app for changed mediaplayer@patapon.info
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0615 Gs  no app for changed LogOutButton@kyle.aims.ac.za
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0618 Gs  no app for changed TopIcons@phocean.net
Okt 03 00:51:39 aldebaran gnome-software-service.desktop[608]: 22:51:39:0622 Gs  no app for changed zeitmaschine@xundeenergie.at
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: make updates: False
Okt 03 00:51:39 aldebaran nm-dispatcher[28518]: CMDLINE con-on 1  2 connectivity-change
Okt 03 00:51:44 aldebaran systemd-logind[655]: Delay lock is active (UID 0/root, PID 705/NetworkManager) but inhibitor timeout is reached.
Okt 03 00:51:44 aldebaran systemd[1]: Reached target Sleep.
Okt 03 00:51:44 aldebaran systemd[1]: Starting Suspend...
Okt 03 00:51:44 aldebaran systemd-sleep[28554]: Suspending system...

Der Rechner suspended, schaltet aber trotzdem ab.
Das Skript '/etc/NetworkManager/dispatcher.d/pre-down.d/stop-services.sh' hat keine Executable-Rechte, da ich nicht will, dass es ausgeführt wird.
Ich hab noch ein zweites selbstgeschriebenes Skript im Dispatcher, welches die Zeilen "nm-dispatcher[28518]" ausgibt. Dieses Skript prüft auf die Connection-id von NetworkManager und setzt dementsprechend den Default-Printer.

Ich habe jetzt mehrere mögliche Ansatzpunkte, da es der NetworkManager zu sein scheint, der das Suspending torpediert.

Manchmal benötigt cups EWIG, um eine Anfrage oder ein Ändern des Default-Printers zu beenden.
Meine Internetverbindung und auch die WLAN-Verbindung scheint äußerst instabil zu sein. Plastik-Router vom Provider... Oft ist es so, dass pings zu Websites extreme Latenzen haben, aber der Router ist sehr schnell beim Antworten. Und ein anderes Mal erreiche ich den Router kaum beim Pingen, Websites dementsprechend langsam bis nicht.
Kann so eine instabile WLAN-Verbindung den Networkmanager beim Suspenden des Systems so derart blockieren, dass der Rechner sich abdreht statt suspended?
Oder liegt das Problem bei logind?

lg scientific

[bullgard]

Leider habe ich keine Angabe zur Debian-Version gefunden.
Wenn Du Kernelversion 4.9 verwendest: So etwas debuggt man gemäß /usr/share/doc/linux-doc-4.9/Documentation/power/basic-pm-debugging.txt.

[scientific]

Tritt bei 4.9, 4.12 und 4.13 auf.

Ich hab tlp im Einsatz.

Es ist stretch im Einsatz.

Ich vermute den Networkmanager oder den WIFI-Treiber... iwlwifi...

[scientific]

Ich glaub, ich hab den Fehler gefunden.

Ich habe ein selbstgeschriebenes Fuse-Filesystem, welches meine Snapshots pro User in ein Verzeichnis mapped.
Dieses wird per Service-Unit gemountet, wenn das Verzeichnis ~/backup vorhanden ist (eine Path-Unit ist dazu auch notwendig).
Ich hatte die Abhängigkeiten der Units falsch gesetzt. Denn sobald ich in dem Verzeichnis gestanden bin, hing der Suspend und die Maschine schaltete sich dann ab. (was prinzipiell ein seltsames Verhalten ist).
War ich nicht in dem Verzeichnis, dann lief der Suspend problemfrei durch. Das Erklärt auch das Verhalten, dass das beschriebene Phänomen nur gelegentlich aufgetreten ist - unabhängig der Kernel-Version.

Ich setze den Thread auf gelöst.

lg scientific

[scientific]

Nein, das wars doch nicht...

[scientific]

Ich hab festgestellt, dass auch beim Ausschalten nach dem erreichen des Shutdown-Targets der Rechner hängt.

Bei diesem STAND IM shutdown-Prozess (hab shutdown, nicht reboot gewählt, trotzdem stht da reboot...) blinkt der Powerbutton ca eine bis 1,5 Minuten, und dann ist der Strom aus.
Das passiert genauso auch beim suspenden.

Meist passiert das, wenn der Rechner länger läuft. Wenn ich einschalte und kurz drauf suspende oder abschalte, geht das ratzfatz und so wie es soll.

Ich steh echt an, da Debuggen eeeinfach auch so unheimlich viel Zeit braucht, da der Rechner eben lange laufen muss, damit es passiert...

Ich muss noch einen Eigenbaukernel bauen, mit speziellen Optionen aktiviert, welche die Meldungen nach dem Beenden des Syslogs beim Reboot ausgenen lassen...

Hat jemand eine Idee?

[scientific]

Ich hatte mittels Powertop einige Optimierungen in rc.local geschrieben.
Hab die mal alle deaktiviert, vor ein paar Tagen. Seither schaut es so aus, als ob Suspend2RAM und auch das Abschalten wieder einwandfrei klappt.

Bevor ich den Thread auf gelöst setze, beobachte ich aber noch weiter. Vielleicht finde ich ja sogar noch raus, welche der Einstellungen der Übeltäter ist.

Lg scientific