suspend-then-hibernate: add option to force early hibernate

[junocomp]

systemd version the issue has been seen with

252-2

Used distribution

Debian Bookworm

Linux kernel version used

6.0.0-2-amd64

CPU architectures issue was seen on

x86_64

Component

No response

Expected behaviour you didn't see

Since 252 I can no longer suspend-then-hibernate using systemctl suspend-then-hibernate.

If I execute the commands to suspend only it does work, same for hibernate. But not in combination

UPDATE: I tested on Manjaro which is using systemd 251.7 and is working fine.

[bluca]

What does "not work" mean? Describe the problem in details, and pastebin verbose logs

[junocomp]

@bluca As I mentioned on my main post.

When executing suspend-then-hibernate it will go into Suspend mode but it will not follow into Hibernate after. This is what my login.conf and sleep.conf look like.

[Login]
HandleLidSwitch=suspend-then-hibernate

[Sleep]
HibernateDelaySec=300s

I checked dmesg but it doesn't show any errors. If you have any other way of tracking it, then I can paste it here.

[bluca]

That's expected, see the manpage. Hibernate will happen when low on battery.

[junocomp]

@bluca I think you are miss understanding my issue. I did have it working before systemd 252.

[bluca]

https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html#suspend-then-hibernate

[TriMoon]

@junocomp I think you are miss understanding my issue. I did have it working before systemd 252.

Maybe the functionality was broken in v252 and is now fixed 🤔
The documentation @bluca linked to clearly states that hibernation will only happen if the system is woken via the ACPI low-battery (<5%) signal.
Otherwise suspend-then-hibernate will behave just like suspend only.
So you might need to change your settings to do a hibernate instead.

Maybe we need an extra setting in Manjaro-KDE to set a time period for hibernate that kicks in after the sleep setting 🤔
So that we can configure this scenario, which will happen in sequence:

1. Screen-off after x time amount.
2. Sleep after y time amount.
3. Hibernate after z time amount.

Where the hibernate kicks in at x+y+z time amount.

There seems to be a setting already which sounds like that but i have no idea how to configure that last delay, and if it indeed does what i said above...

[junocomp]

I set mine to go into suspend-then-hibernate by default.

rm /usr/lib/systemd/system/systemd-suspend.service
ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /usr/lib/systemd/system/systemd-suspend.service

Either way, if I execute the systemd command or wait until it gets to 5%, hibernate is never followed after suspend.

[TriMoon]

@junocomp,
I set mine to go into suspend-then-hibernate by default.

rm /usr/lib/systemd/system/systemd-suspend.service
ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /usr/lib/systemd/system/systemd-suspend.service

Either way, if I execute the systemd command or wait until it gets to 5%, hibernate is never followed after suspend.

Looks like you are messing manually with your systemd there 🤔
I wouldn't suggest messing like that before you absolutely know what your're doing...

Why didn't you choose the documented way to configure stuff?

On my current Manjaro, See:

#> man systemd-suspend-then-hibernate.service`
#> man systemd-sleep.conf`
#> systemd-analyze cat-config systemd/sleep.conf

# /etc/systemd/sleep.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the sleep.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# See systemd-sleep.conf(5) for details.

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendMode=
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateState=disk
#HybridSleepMode=suspend platform shutdown
#HybridSleepState=disk
#HibernateDelaySec=120min

To change settings it's highly recommended to create "drop-ins" in the /etc/systemd/sleep.conf.d/ subdirectory...

Here is the current original contents on my Manjaro for you to be able to restore the file you removed:

• Output of systemctl cat systemd-suspend, remove the first line ofcourse 😉

# /usr/lib/systemd/system/systemd-suspend.service
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=System Suspend
Documentation=man:systemd-suspend.service(8)
DefaultDependencies=no
Requires=sleep.target
After=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/systemd-sleep suspend

Like with all changes to systemd's config files, always do a systemctl daemon-reload afterwards, when you made some changes to any config of systemd...

Anyhow i don't use this stuff at moment on my desktop, but you might try these pointers 😉

[n-peugnet]

@bluca:

https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html#suspend-then-hibernate

Well this is a little bit easy to refer to the latest docs which changed since v252.

On v251 the manual entry for this option was:

 suspend-then-hibernate
       A low power state where the system is initially suspended (the state is stored in RAM).
       If not interrupted within the delay specified by HibernateDelaySec=, the system will be
       woken using an RTC alarm and hibernated (the state is then stored on disk).

Why did this change instead of creating another power saving mode (for instance suspend-then-hibernate-on-low-battery)?
How to use the previous behaviour?

I dont want my computer to stay in S3 state when it is >5% battery. I want it to go to S4 state after HibernateDelaySec of S3 state.

[bluca]

That is not supported anymore, as it was half-broken and made very little sense, it was just a workaround for missing functionality that is now implemented. If you want to hibernate it immediately, then just do that.

[n-peugnet]

If you want to hibernate it immediately, then just do that.

I don't want to hibernate. Resume from hibernation is around 45s on my system while resume from suspend is instantaneous.

I want to always suspend, then after 30m hibernate. If I need to quickly reuse my computer after I suspended it, it resumes instantaneously. And if I need to use it later, then I can probably wait 45s, so I want it to hibernate to save power.

[bluca]

Why 30 minutes and not, say, 4 hours?

[n-peugnet]

Why 30 minutes and not, say, 4 hours?

Why is it important? This is my setup, which was previously configurable with HibernateDelaySec. I happen to like the value of 30m (in fact I just checked and I used 45m, but I don't see the point of this question).

---

I also have this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023483 which is a little bit different, and forced me to rollback to v251. Should I open a new issue here for this ?

It might be related to #24336

[junocomp]

@n-peugnet I also had to downgrade

[yuwata]

Tentatively reopen this to make more users can easily find this 'issue' and join the discussion. Though, I am not sure the current behavior is expected or not.

[bluca]

The current behaviour is fully expected and documented

[yuwata]

Hmm, but as reported, v252 changes the behavior. That's true regardless of it is expected or not.

How about to honor the setting if specified instead of using ACPI_BTP or calculated discharging rate?
And/or, introduce another knob(s) to control the interval for calculating discharging rate?

Anyway, please do not close this page so quickly.

[feluxe]

I think it is better to make HibernateDelaySeconds= specify the maximum amount of suspend time to keep backward compatibility.

Yes, please. This breaking change cost me countless hours and pain over the last few days, because I was debugging a dead end: https://bbs.archlinux.org/viewtopic.php?id=281373

I also miss the old behaviour of HibernateDelaySeconds...

[OJFord]

Why 30 minutes and not, say, 4 hours?

The use case of "I happen to like the value of 30m" is not sensible and definitely not something to support.

Where's this '30m' coming from @bluca? Mine was set to 2h and working nicely as I intended it to.

If you want to hibernate it immediately, then just do that.

I don't want to hibernate immediately - consider using a laptop in an office for example, you close it to take it to a meeting room, re-open it a few minutes later, you don't want to wait for resume from hibernation.

But if plans change and it ends up suspended for hours, I want to save the battery and probably don't mind the start-up delay so much coming back to it after a longer period.

(That's just for illustration - my usual use case is actually at home with a personal laptop, using and closing, not knowing if I'll use it again or not that evening, but if I do it's probably for something quick and won't be bothered if it takes too long. But if I don't, I don't want it suspended all night.)

Yes, and it was a 6-months long project, widely advertised and listed in the changelog as expected.

I appreciate the effort that has gone in to this related work, but I checked the changelog; there's this, buried in 'changes to other components', not mentioned as a compatibility break - the only mention of 'hibernate' (and not the HibernateDelaySeconds option at all):

    * When performing suspend-then-hibernate, the system will estimate the
      discharge rate and use that to set the delay until hibernation and
      hibernate immediately instead of suspending when running from a
      battery and the capacity is below 5%.

To me, that's not at all clear that it will now never hibernate while powered; nor that with the delay option manually set to a fixed value it will power off (with potential data loss!) if the battery runs flat. (I'm not sure that's intended, sounds like not - though I'm unclear with the behaviour change why the option still exists at all - but seems to be what's happening.)

[man page HibernateDelaySec] The amount of time the system spends in suspend mode before the RTC alarm wakes the system, before the battery discharge rate can be estimated and used instead to calculate the suspension interval. systemd-suspend-then-hibernate.service(8). Defaults to 2h.

Oh, so I suppose that's why - I experience the above when the battery is insufficient to last for HibernateDelaySec? But then that still clearly can lead to data loss? I had some other mechanism for hibernating on low battery, it seems that's stopped working, probably unrelated, but the result of this option now being interpreted as 'wait before beginning to determine whether to hibernate on low battery' is that with my existing value of 2h it hasn't happened in time so I've had the data loss that it sounds like this project was intended to prevent anyway.

[ezhukov]

@bluca:

Nah, supporting setups that can lead to data loss is a bad idea.

Then you might also consider removing the suspend only mode.

Indeed, the default suspend setup can easily lead to a battery loss. Charge goes to zero, the battery gets permanently damaged and won't charge anymore. Happened to me once, using suspend-then-hibernate ever since.

[ailin-nemui]

while it's nice that it will hibernate if there is only 5% power left, there is one big benefit if we can get back force early hibernate:

if you can set it to hibernate after 30 minutes (as it was possible previously), then your computer will have 90% battery!!

This is very important if you need to continue working on it and do not have a charger, something that the new (and only) mode makes impossible and would require a careful manual hibernate planning now

[jojoob]

I'm a bit late to the party but want to put my two cents anyway:

I think the fact that this was a breaking change for the "HibernateDelaySec" option for that, at least, I didn't found a reference in the release notes should be argument enough to restore the previous functionality. Don't get me wrong, I appreciate the new feature for guarantee hibernation on low battery. But if it had been possible to maintain backward compatibility this should be considered as a regression.

that's a weird use case but fine I guess

One use case is to safe battery as @n-peugnet described. My use case is to combine fast resume within the configured delay (comfort) and automatically secure the system after that delay with hibernation (suspend to disk) with full disk encryption (security).

[DianaNites]

This is a serious security regression, as anyone who was relying on systemd to do what it said it would until version 252 is now potentially vulnerable. I need my (fully encrypted, verified boot) system to hibernate when I tell it to for security reasons, and until recently it did. And now it doesnt.

This is an extremely serious vulnerability and its baffling theres been a month of "debate" on whether a silent, backwards incompatible change, to an existing feature and option, that causes real world security issues is a problem or not.

Before anyone gets into it: Your threat model is not my threat model. This is within mine, and i'm sure also within plenty of organizations.

Not to mention the basic usability issues, I for one like to come back to my laptop and resume where I left off with my battery where I left it, not empty or at 5%.

[jojoob]

@DianaNites I would not name it a serious security regression. You can still just hibernate your system to secure the sleep state with full disk encryption. And I wouldn't rely too much on the interrupt for hibernate after a delay when your security concerns are strong. ;)

Meanwhile, anyone who can't wait for the feature to return and isn't able to downgrade can work around the regression by using a custom suspend-then-hibernate script. I once wrote one for the purpose of using uswsusp with systemd but it can be adopted easily.

---

I also have this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023483 which is a little bit different, and forced me to rollback to v251. Should I open a new issue here for this ?

@n-peugnet you did you not open an issue for that, or did you? I have a very similar problem on Arch since updating from v252.1 to v252.2. Maybe you could check if v252.1 works for you as well.

[n-peugnet]

@jojoob:

I also have this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023483 which is a little bit different, and forced me to rollback to v251. Should I open a new issue here for this ?

@n-peugnet you did you not open an issue for that, or did you? I have a very similar problem on Arch since updating from v252.1 to v252.2. Maybe you could check if v252.1 works for you as well.

This issue is tracked there: #25356

[DianaNites]

Just because it can be worked around doesn't mean it isnt a regression. The behavior worked and was secure, and an update made it not. Thats called a security regression.

Now if everyone who was using it wants that same security, they have to first know about this issue somehow(CVE?), and then manually work around it until the proper fix comes out.

[bluca]

Given trolling has started, time to lock