Am 22.10.2017 um 13:43 schrieb Michal Suchanek: > 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.
Please try to use a less obnoxious tone. Otherwise my interest in helping you drops to zero. Please try downgrading the kernel to the previous version and report back. >> >>> 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. A reboot is the safest way to get a clean state. Which is helpful when debugging to avoid any other side effects. >> 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. A suspend or hibernate will not give you a new bootid. But as you figured out, you didn't actually get a hibernate, but a full boot as resume from hibernate failed. That said, you can enable persistent journal by creating the directory following the instructions in /usr/share/doc/systemd/README.Debian.gz > 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. > What exactly did you disable and how? Are you using the hibernate tool from the "hibernate" package? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature