On 21 October 2017 at 17:13, Michael Biebl <bi...@debian.org> wrote: > Control: severity -1 normal > Control: tags -1 moreinfo > > Am 21.10.2017 um 14:29 schrieb Michal Suchanek: >> Package: systemd >> Version: 232-25+deb9u1 >> Severity: important >> >> Hello, >> >> after recent upgrade I was unable to wake up from suspend. > > Which packages were updated?
Hard to tell. Have any handy utility to get that from dpkg log? With grepping I found the only remotely related packag is dbus and of course the kernel. > systemd in stable was not updated for 9.2. Yes, it seems the case. > Why do you suspect that systemd is the culprit Because it insists on doing everything so when anything breaks it's systemd's fault. In particular it took over handling power key so when power key handling breaks it's systemd's fault. > >> Examining the system closely during suspend/resume the system suspends, >> then resumes, then hibernates, and tehn fails to resume from >> hibernation. It is quite possible that in some cases it hibernates >> straight away and fails to resume from hibernatiion on next boot >> wiithout ever suspending. >> > > Are you using hybrid suspend? How do I tell? I told systemd to suspend my system when power key is pressed. Even if it used hybrid suspend it should suspend to disk and ram at the same time and not one ofter another. > What is triggering the > - suspend power key > - resume power key > - hibernate bug > - resume from hibernation power key > > A debug log for logind might be helpful as well. For that run > systemctl edit systemd-logind, then add > [Service] > Environment=SYSTEMD_LOG_LEVEL=debug > > This will create a file > /etc/systemd/system/systemd-logind.service.d/override.conf. Then reboot Yes, right. logind cannot be reconfigured while system is running? I guess 'telinit q' or 'systemctl daemon-reload' followed by restart of logind should work as well. > and attach the output of > journalctl -b -u systemd-logind.service > after you reproduced the issue. It does not contain any relevant data because -b selects the current boot and the system suspended in the previous boot. Using -b -1 gives Specifying boot ID has no effect, no persistent journal was found So much for producing logs of the issue. However, I noticed that I have hibernate logs and comparing earlier hibernate logs with recent ones I can see that earlier logs have an error saying the s2d device is not available while recent hibernate logs say the system was suspended to disk. Disabling any suspend methods in hibernate resolves the problem. Looking through the logind log I see no reference to hibernate, though. So what runs hibernate(8) is a mystery. And presumably hibernate putting the system to sleep should avoid systemd doing the same or the other way around. Best regards Michal