Fedora reawakens the hibernation debate [LWN.net]

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 17:15 UTC (Mon) by mcortese (guest, #52099)
Parent article: Fedora reawakens the hibernation debate

I'm confused. Doesn't resuming from hibernation require a resume= parameter passed to the kernel at boot? How is GNOME or systemd supposed to set (or check) that parameter before enabling hibernation?

to post comments

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 17:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

There's an ioctl() that allows to set this parameter on the running kernel.

It's been broken for ages for hibernation files, though.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 18:59 UTC (Mon) by mcortese (guest, #52099) [Link] (8 responses)

But when in the boot process is that ioctl() called?

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 19:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

I would expect in initrd. It then will load the old kernel and replace the running image.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 21:18 UTC (Mon) by mcortese (guest, #52099) [Link] (6 responses)

Then I need to rephrase my original question: how can GNOME or systemd set (or check) initrd to include the resume part?

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 21:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

The way I would do it - create a flag file on the root partition of the system, so during the boot up the initramfs mounts the root volume as RO and checks for this flag. If it can find it, it reads the suspend image and checks for the presence of the suspend signature.

If it's present, attempt the resume (via another IOCTL). The kernel reads the saved image, does the CRC check and if everything is OK the control is transferred to the saved image.

Fedora reawakens the hibernation debate

Posted Oct 9, 2018 16:22 UTC (Tue) by mcortese (guest, #52099) [Link] (4 responses)

I see so many ways this approach can fail.

Mounting root... But root could be in a non-clean state.

Initramfs... So now systemd or GNOME depends on Initramfs? Last time I checked, Debian packages had no dependence on a specific version of the kernel. Or on the existence of a boot partition or of a specific bootloader.

In fact I have run a Debian system for years (systemd & GNOME) with no initramfs, no boot partition except EFI, and no bootloader. I guess I'd better think twice before upgrading to GNOME 3.30... :)

Fedora reawakens the hibernation debate

Posted Oct 9, 2018 17:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

If root is a non-clean state then you can’t use it for resume anyway, so no problem here.

Fedora reawakens the hibernation debate

Posted Oct 11, 2018 21:17 UTC (Thu) by mcortese (guest, #52099) [Link] (2 responses)

> If root is a non-clean state then you can’t use it for resume anyway, so no problem here

Why? At any time the fs on disk can be non-clean while the vfs has pending changes not landed on disk yet. If the system is suspended in that moment, it's frozen in that precise state. If it's then hibernated, that state is written to swap.

For resume to work in such case, neither the kernel nor the initramfs must reside in the root fs.

This is just an example of the several conditions systemd should check before asserting that the system is ready for hibernation. Now, after reading the whole Fedora thread, I understand that systemd does nothing more than checking if the free swap is equal or greater than the used RAM. So when it says "CanHibernate" it actually means: this system *could* be configured to hibernate but I have no idea if it really is.

My opinion is that GNOME should not silently default to use hibernation only based on systemd's CanHibernate flag.

Fedora reawakens the hibernation debate

Posted Oct 11, 2018 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

As a part of the hibernation process the pending writes are flushed and the IO is quiesced. So if you have a dirty FS then you can be sure that it's not been used for hibernation.

Fedora reawakens the hibernation debate

Posted Oct 13, 2018 19:18 UTC (Sat) by mcortese (guest, #52099) [Link]

I didn't know that. Thanks for pointing it out.

So, while suspend & resume is nearly transparent for the running processes, hibernate & resume heavily changes the system's internal state.

I wonder if hibernation can stall in case of big IO backlog?

Fedora reawakens the hibernation debate

Posted Oct 10, 2018 15:30 UTC (Wed) by cortana (subscriber, #24596) [Link] (3 responses)

It's not done by GNOME/systemd but by the installation process. You mention you're on a Debian system. In your case, the installer would have set RESUME= in /etc/initramfs-tools/conf.d/resume to point to a swap device. This is copied into the initramfs when it is generated. At boot time, /usr/share/initramfs-tools/scripts/local-premount/resume makes that device available and then uses klibc's resume command to actaully perform the resume by writing the swap devices's major:minor:offset to /sys/power/resume.

Fedora reawakens the hibernation debate

Posted Oct 13, 2018 18:05 UTC (Sat) by mcortese (guest, #52099) [Link] (2 responses)

Thank you for your explanation.

I still think it's fragile. This behavior of GNOME implicitly depends on initramfs. I think it should be made evident with a Depends-type relationship between the relative packages, otherwise a user could be tempted to use a kernel that doesn't need any initramfs and lose her unsaved data the first time she suspends her laptop for 3 hours after upgrading GNOME!

Fedora reawakens the hibernation debate

Posted Oct 16, 2018 8:32 UTC (Tue) by cortana (subscriber, #24596) [Link] (1 responses)

I'm sure the systemd folks would welcome patches to make logind's CanHibernate logic more robust!

Fedora reawakens the hibernation debate

Posted Oct 17, 2018 6:47 UTC (Wed) by mcortese (guest, #52099) [Link]

No automatic tool can detect if all the pieces are in place for a successful resume. The only sane choice would be to default to No unless the user explicitly opts in.