The former “suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called suspend to both.”
The latter “initially suspends the system to RAM and if it is not interrupted within the delay specified by HibernateDelaySec in systemd-sleep.conf(5), then the system will be woken using an RTC alarm and hibernated.”
I had hibernation running on my last laptop because I often was coding from the bus. I don’t use it anymore. Everything boots quick enough and it’s a way to ensure I restart things like Chrome or Slack that are memory hogs.
On Linux I have found this to be VERY true. However on Windows not so much. At any rate restarting the whole system instead of the process is not my preferred method. But this is an important point nonetheless: A fresh system has many other benefits that might not be captured by a system that hasn’t been restarted in months.
Honestly I get enough system restart simply from updating components and then requiring a restart.
The funny thing is in 18.04 they changed the default swap size in the installer to 1 GB because ‘nobody needs more than that with large amounts of RAM’. Oh boy the Launchpad issues around that get spicy. I ended up finding a custom partitioning script to use in my preseed file to make a large enough swap to hibernate.
I honestly didn’t realize that Linux had abandoned hibernation! To be fair, I did a Debian minimal install on my current (non-Framework — I’m batch 5!) with manual partitioning to setup full disk encryption (including encrypted swap), so I’m not exactly a “install using defaults” kind of person.
I fully concur with you that hibernation is wonderful, especially for someone who uses LUKS.
There are no issues with battery drain.
There are no issues with attempting to lock and unlock LUKS devices, since the computer turns off.
The second one is interesting because for the longest time, people sort of wrote off suspend as “less secure” than hibernate, since the LUKS devices wouldn’t be suspended (and so their contents could still be accessed). However, recently, people wrote up integrations with systemd and such to automatically lock LUKS devices before suspend and prompt to unlock them before resuming. However, this was (last I checked) still prone to quite a few bugs, to the point that I stopped using it and just started hibernating.
Hibernation really is a nice sweet spot between suspend and shutdown. It lets you resume your work (like suspend) while preventing any issues should your computer run out of power (like shutdown).
Hibernation is hibernation. Sleep and deep sleep are similar but different. As far as the differences, I imagine deep sleep shuts down more while in standby then traditional sleep. However in any sleep case, whether it is deep or not, you will be loosing battery over time.
With hibernation your computer is off and your work session saved. You are not loosing any power at all, as the computer is off.
I only use suspend because I can get power draw there low enough that I don’t care, and I’m (possibly unnecessarily) worried about the ssd write cycles if I had a swap file that I wrote my whole ram contents to multiple times a day. I’ve already written too much to my disk while distro-hopping and I’d like to preserve what I can because I’ve already had too many data scares and I don’t want to have to buy a new drive in the next several years at school. Even if it is all backed up, I want to do everything I can to avoid that eventuality.
@epchris hibernation saves the contents of RAM to a file on the drive then shuts the computer off entirely. It’s not as popular on Linux since typically there isn’t good enough driver support from vendors to ensure all the internal devices resume from hibernation nicely.
I’m on Arch and trying to get the linux kernel to hibernate properly but it’s failing to do so . I’ve got all the kernel parameters (e.g. “resume=UUID=xxxx” going and suspend to RAM works fine, but the hibernation itself always just results in a fresh reboot.
The linux kernel documentation on debugging the hibernation settings narrowed it down to a possible “platform firmware” problem, but I’m kind of stuck now.
As impractical as a forum is for discussing this, I’ll give it a shot anyway:
So you have initramfs updated to reflect the swap partition you are hibernating to? If you just updated GRUB and not initramfs then this could be your problem.
In general hibernation on Linux works, and the firmware isn’t a problem. I’ve done this on Fedora and Ubuntu.
No worries! Hibernation is a very important function to me. I still don’t understand why Linux desktop just moved away from it without any explanation. it clearly works and is useful when you need it.
The last hibernation did have an issue when I resumed the device the wifi didn’t work and iwctl did not show my adapter. The next time it happens I’m going to try to poke at it to see if I can at least restart it to get wifi working without a reboot.
Overall very impressed with power management via systemd on Arch. We’ll see if I continue to have issues with it.
Maybe you can do a sudo rmmod iwlwifi && sudo modprobe iwlwifi or such? I’ll see if I run into the same issue when I get mine, since I basically use hibernate by default nowadays (more reliable than sleep, drains basically no power, and quick enough to boot that I don’t have to factor that in).
. I’ve got all the kernel parameters (e.g. “resume=UUID=xxxx” going and suspend to RAM works fine, but the hibernation itself always just results in a fresh reboot.