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

[Michael Biebl]

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>