Fedora reawakens the hibernation debate [LWN.net]

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 23:30 UTC (Thu) by gerdesj (subscriber, #5446)
In reply to: Fedora reawakens the hibernation debate by devil
Parent article: Fedora reawakens the hibernation debate

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

to post comments

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.