Fedora reawakens the hibernation debate [LWN.net]

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 13:03 UTC (Mon) by cuboci (subscriber, #9641)
Parent article: Fedora reawakens the hibernation debate

It seems to have found its way into Debian/unstable, as well. I had to turn it off by masking the appropriate systemd target (systemctl mask suspend-then-hibernate.target) because it was annoying me to no end to have to wait in the morning for the machine to be ready to use.

to post comments

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 18:16 UTC (Mon) by devil (guest, #99595) [Link] (4 responses)

Debian has it because it is a systemd.target. But it is inactive per default. You can check with 'systemctl show suspend-then-hibernate.target | grep -i activestate' on a freshly installed debian, no matter if sid, testing or stable. Debian's systemd maintainers are quite sensible in what they activate.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 7:40 UTC (Tue) by smcv (subscriber, #53363) [Link]

The systemd target is not normally used by systemd itself (all of the HandleWhatever options in /etc/systemd/logind.conf support "suspend-then-hibernate", but none of them have that as their default).

However, while a GNOME session is running, gnome-settings-daemon takes over responsibility for power policy (to make it configurable per-user), and gnome-settings-daemon 3.29/3.30 uses suspend-then-hibernate (if supported) in situations where previous versions would have used suspend: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issu...

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 23:30 UTC (Thu) by gerdesj (subscriber, #5446) [Link] (2 responses)

$ cat /etc/os-release
NAME="Arch Linux"
...
$ systemctl show suspend-then-hibernate.target | grep -i activestate
ActiveState=inactive

Arch generally leaves things at upstream defaults but I have done no further research on this particular issue.

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 23:42 UTC (Thu) by mchapman (subscriber, #66589) [Link]

Looking at the ActiveState for suspend-then-hibernate.target isn't particularly insightful. It will only be active when something chooses to actually start it, and after the system has been resumed and all of the units that it pulled in are stopped again it will become inactive again (since it has StopWhenUnneeded=yes). It's not the kind of target that is activated at boot.

So the command you've run there will produce the same output even on Linux distributions that have chosen to try it out.

Fedora reawakens the hibernation debate

Posted Sep 21, 2018 15:14 UTC (Fri) by ejona86 (subscriber, #43349) [Link]

I'm on Arch and noticed the change, probably due to the GNOME 3.30 update. I was a bit amazed that hibernate worked as I had configured a resume= partition on my kernel command line years ago when setting up my system but had never tested it. My only worry is about kernel updates preventing resume due to runtime vs /boot version mismatch.

But due to the longer resume time I almost immediately changed sleep.conf so that HibernateMode=suspend-to-both. My laptop drains power very slowly with suspend-to-mem such that in two years I've yet to run out of battery while suspended. So I might even disable hibernate completely. But it is a bit of a shame that I'd have to disable hibernate for the entire system via systemd just because of GNOME's behavior.

I'd probably be more likely to use it if it was based on battery level instead of time. But I believe that's generally infeasible.