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

[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.

>
>> 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