sleep und hibernate werden 2x ausgeführt

[hupfdule]

Hallo,

ich habe gerade ein Notebook von wheezy über jessie auf stretch geupdated. Und nun habe ich das Problem, dass das Auslösen von von hibernate und sleep immer 2x ausgeführt wird (also nach dem Aufwachen sofort wieder in den sleep/hibernate-Modus geschaltet wird).

Vorher mit acpid hatte ich dieses Problem nicht. Das wird ja nun von systemd erledigt. acpid ist daher auch nicht installiert.

Ich hatte ja eigentlich vermutet, dass sowohl systemd, als auch e17 nun den ACPI-Event fangen und bearbeiten, aber auch ein Deaktivieren des Events in e17 hatte nichts gebracht.

Meine Frage daher: Wie kann ich feststellen, welche Prozesse die ACPI-Events bearbeiten?

[BenutzerGa4gooPh]

Wie kann ich feststellen, welche Prozesse die ACPI-Events bearbeiten?

Das Journaling sagt einiges zu ACPI.
http://www.linux-magazin.de/Ausgaben/20 ... md-Journal
Für deine Probleme evtl. dauerhaft/persistent einschalten
https://www.freedesktop.org/software/sy ... .conf.html
Fehler provozieren und mit Zeitbereich auslesen.

Code: Alles auswählen

journalctl --since "2017-06-26 23:15:00" --until "2017-06-26 23:20:00"

ich habe gerade ein Notebook von wheezy über jessie auf stretch geupdated. Und nun habe ich das Problem, dass das Auslösen von von hibernate und sleep immer 2x ausgeführt wird (also nach dem Aufwachen sofort wieder in den sleep/hibernate-Modus geschaltet wird).

Altlasten? Neuinstallation in Erwägung ziehen?

acpid ist daher auch nicht installiert.

K. A. ob so korrekt. Neue Ideal-Standard-Install. würde es zeigen und korrigieren. Bin gerade nicht am PC, morgen sehe ich nach. So ich dran denke.

Nach Paketbeschreibung wahrscheinlich nötig: https://packages.debian.org/stretch/acpid

[BenutzerGa4gooPh]

Code: Alles auswählen

su
top
...
966 root      20   0    6304   1692   1536 S   0,7  0,0   0:02.13 acpid  
...

War zu erwarten.

Wenn man

Code: Alles auswählen

journalctl -b

anschaut, kümmert sich bereits der Kernel um ACPI.
Beim Schließen des Deckels meines Lappis (S3 / Suspend to RAM / Bereitschaft) kümmern sich Kernel und systemd. Verrät mir ebenfalls das Journaling.
Dafür nur

Code: Alles auswählen

journalctl

eingeklimpert.

Damit dürften einige deiner obigen Vermutungen nicht stimmen. Kannst nun selbst auf deine Konfiguration bzw. notwendige Maßnahmen schließen.

[hupfdule]

Hallo und sorry für die späte Antwort.

Eine Neuinstallation wollte ich eigentlich vermeiden. Das ist wieder zusätzlicher Aufwand.

Ich hatte bereits mit journalctl nachgesehen, aber nichts für mich verwertbares gefunden.

Allerdings habe ich eine neuere Version von e17 installiert (also e21). Und dort tritt dieses Problem nicht mehr auf. Offenbar arbeitet die e17-Version aus stretch nicht sauber mit systemd zusammen.

Da das mit der neueren Version funktioniert, denke ich die Ursache gefunden zu haben.
Vielen Dank für deine Hilfe!