Bug#879277: systemd: After resume from suspend to ram system immediiately hibernates
Hello, On 22 October 2017 at 14:14, Michael Biebl wrote: > Am 22.10.2017 um 13:43 schrieb Michal Suchanek: > Please try downgrading the kernel to the previous version and report back. Downgrading the kernel is not really an option. It was broken so I did not keep a backup and the build is gone from the archives. > That said, you can enable persistent journal by creating the directory > following the instructions in /usr/share/doc/systemd/README.Debian.gz I will keep that filed in case I do have some logs to collect. > >> 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? All suspend methods in /etc/hibernate.conf > Are you using the hibernate tool from the "hibernate" package? I would not say exactly using. I have it installed and hooked to the acpid scripts but long time ago when I upgraded to Debian version that requires systemd it stopped working because systemd took over handling the power key. Now it is obviously hooked to something somewhere again because it runs in parallel to the systemd power button handling. This is quite unfortunate. I am not aware of doing anything that would re-enable it. My expectation is that only one package handles power button. Thanks Michal
Bug#879277: systemd: After resume from suspend to ram system immediiately hibernates
Am 22.10.2017 um 13:43 schrieb Michal Suchanek: > On 21 October 2017 at 17:13, Michael Biebl 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
Bug#879277: systemd: After resume from suspend to ram system immediiately hibernates
On 21 October 2017 at 17:13, Michael Biebl 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
Bug#879277: systemd: After resume from suspend to ram system immediiately hibernates
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? systemd in stable was not updated for 9.2. Why do you suspect that systemd is the culprit > 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? What is triggering the - suspend - resume - hibernate - resume from hibernation 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 and attach the output of journalctl -b -u systemd-logind.service after you reproduced the issue. -- 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
