Bug#879277: systemd: After resume from suspend to ram system immediiately hibernates

Michael Biebl biebl at debian.org
Sun Oct 22 13:14:13 BST 2017

Am 22.10.2017 um 13:43 schrieb Michal Suchanek:
> On 21 October 2017 at 17:13, Michael Biebl <biebl at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20171022/edb57d3a/attachment-0002.sig>

More information about the Pkg-systemd-maintainers mailing list