Completely shutting down a computer can be undesirable when having many important tasks or windows open, or needing to interrupt work for only a few hours to them resume it later. To solve this problem, computers have long supported a "sleep" state that allows "freezing" the current state of the machine and "unfreeze" it quickly later on.
The different kinds of sleeping states
In modern linux systems using systemd
, sleep functionality is managed by the systemd-sleep
component, which supports four different kinds of sleep states:
suspend
(aka "standby" or "suspend to ram"): Freezes the contents of system memory (ram) and turns off all components, except for the minimal amount of power to keep memory contents alive. Very fast to sleep/resume, but loses state if power is lost.
hibernate
(aka "suspend to disk"): Copies the system memory contents to disk (typically swap file or a swap partition), then fully turns off the computer. On resume, reads stored disk data back into memory and resumes. This mode can survive complete power loss, but can be very slow to sleep/resume, based on the size of memory and the write/read speed of the disk storing the memory contents. Also requires at least as much swap space as system memory, preferrably slightly more.
hybrid-sleep
: Uses bothsuspend
andhibernate
at the same time. This mix is a tradeoff for systems that want to use hibernate with a little extra speed. Entering sleep is still slow (writes memory to disk), but resuming is fast if power was not lost (using suspend resume) or slow if power was lost while sleeping (resume from disk). The only noticeable difference is the system resuming faster from sleep if power was not lost, everything else is as slow as normal hibernate.
suspend-then-hibernate
: Initially enters normalsuspend
mode, but waking up periodically to check battery state. When battery charge becomes really low (typically around 5%), puts the system intohibernate
instead of suspending again. Can use more complex mechanisms like low battery alert signals or setting timers based on average expected battery discharge by only checking once, but core functionality remains the same.
When to pick which sleep mode
With so many options for putting the system into power saver mode, which is right for you? The answer depends on your needs and hardware:
The suspend mode is often the best choice for desktop computers, as it is extremely fast to sleep and resume, and desktops typically have permanent access to a stable supply of power, making the loss of electricity edge cases a non-issue for most users.
Picking hibernate used to be the only alternative to suspend, but with the new dual modes it is really only relevant for systems that do not support suspend at all (thus cannot use hybrid modes). Any other system that doesn't want to use suspend is better served with the two remaining options.
The hybrid-sleep mode is the better version of hibernation with slightly better performance on resume. It is intended for systems that are used in environments with unreliable power sources, or for applications that cannot risk loosing system state (and booting normally) at any cost.
Any device using battery or local power storage, like handhelds, laptops etc are best served with the suspend-then-hibernate sleep mode, as it dynamically accounts for the remaining charge left in the battery and includes active security measures to switch to slow hibernation when necessary, but preferring the fast suspend method when not.
Hibernation might not be what you want
Using hibernation may seem like a more reliable choice at first glance, but it has a lot of hidden issues that need to be considered.
First of all, hibernation requires that system memory contents fit into swap space. In reality, that means if your computer has 16GB of memory, you now need at least 16GB swap space on your disk as well, preferably slightly more to account for actual swap contents. The more memory you have, the more space hibernation will eat off your disk.
Secondly, writing to disk can be a slow process. Going into hibernation means writing memory contents to disk first, no matter how long that takes. A system with a large amount of ram or slow disks can easily spend several minutes before going to sleep, while seemingly being unresponsive.
Lastly, writing system memory to a swap partition is uniquely challenging for systems using full disk encryption (cryptsetup
/dm-crypt
), because their swap partition is on the encrypted disk, which the computer can't read when starting. There are ways around this since LUKS2
using encrypted swap and keyslot adjustments, but that requires users to type in their encryption passphrase to resume and adds CPU load on sleep/resume to en/decrypt memory contents to/from swap, making the process even slower than it was already.
Configure sleep behavior
In order to configure the correct sleep behavior for your system, first make sure your desired sleep state works as expected on your system. For example, to test if suspend
works, run
sudo systemctl suspend
Change the last command to test hibernate
, hybrid-sleep
or suspend-then-hibernate
to change a different mode, respectively.
Once you have found the sleep state you want to use, it is a good idea to disable all the others to prevent the system accidentally using a different one. You can either do this graphically through desktop environments like gnome or kde, or in systemd
directly by editing these lines in /etc/systemd/sleep.conf
:
[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
By default, these lines are commented out (ignored) and show the default setting. To change them, remove the #
symbol at the beginning of the line and change their value. A system that wants to only use suspend
should consider not allowing the other three sleep states, to prevent issues with some desktop environment or program accidentally going into a different sleep state.
There are more specific controls in this file, see man systemd-sleep.conf
. For a better understanding of how sleep states are invoked and managed, see man systemd-sleep
.
Enabling hibernation
Many users don't know about the swap space requirement and experience an unresponsive ("frozen"/"hanging") system when trying to hibernate because the computer cannot fit all memory contents into swap space.
To verify if this applies to your machine, check how much memory and swap space you have available:
free -mh
This shows you two lines of values, the first for system memory, the second for swap:
total used free shared buff/cache available
Mem: 4Gi 2.6Gi 201Mi 160Mi 1.1Gi 1.4Gi
Swap: 979Mi 0B 979Mi
We are only focusing on the total
column: In this example, the system has 4GiB of system memory, but only 979MiB of swap space. Hibernation needs at least as much swap as memory, preferably slightly more. To enable hibernation on this system, you need to increase available swap space. If you don't want to create an entire swap partition, you can quickly create a swap file instead:
sudo fallocate -l 5G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Running the free -mh
command again, you should see more swap space than system memory now:
total used free shared buff/cache available
Mem: 4Gi 2.6Gi 201Mi 160Mi 1.1Gi 1.4Gi
Swap: 6.0Gi 0B 6.0Gi
Before you can hibernate the system it's better to explicitly tell the kernel to use the new swapfile to resume from sleep. Find the line GRUB_CMDLINE_LINUX_DEFAULT
and add resume=/swapfile
at the end. For example, if the line looks like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
it should look like this after editing:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/swapfile"
Make sure you edit the line ending in _DEFAULT,
not the similarly named one GRUB_CMDLINE_LINUX
!
Apply the new configuration:
sudo update-grub
Then test out hibernation again:
sudo systemctl hibernate
It should now work normally. If you still have problems, see troubleshooting steps at the bottom.
Require password after waking from sleep
When resuming from sleep, you may want the system to require you log in again, or specifically not to ask for your password again, whichever you prefer. Configuring these is outside of the systemd
component's responsibility, and needs to be done in your desktop environment instead.
Requiring your password when resuming is tied to the "screen lock" setting of desktop environments. Since most applications have no way to tell if they just resumed from sleep, they instead watch screen state, and let you configure if the computer should lock your user account when the screen goes blank. Note that this also affects blank screen from other sources, e.g. idle/power saver features.
For gnome, those settings are in the control panel under the "Privacy" > "Screen". If you want to lock your account when sleeping, enable "Automatic Screen Lock" and set "Automatic Screen Lock Delay" to "Screen Turns Off".
You might also want to set "idle screen delay" to "never", to ensure your pc doesn't lock after every few minutes of inactivity.
For kde-plasma, navigate to "Security & Privacy" > "Screen Locking" and make sure to check the "Lock after waking from screen" checkbox and set "Lock screen automatically" to "never".
The configuration steps for other desktop environments will be similar, so you can refer to the advice from these two examples when dealing with a different one.
Troubleshooting sleep issues
Sometimes systems may be unable to enter sleep modes because of hardware / driver issues. Troubleshooting these can be difficult, so here are some steps to guide you in the right direction:
Make sure you have the latest updates installed:
sudo apt update && sudo apt upgrade -y
Common issues or incompatibilities are often fixed just by updating the system packages.
If you have an nvidia graphics card, make sure you have installed the latest driver:
sudo apt update && sudo apt install -y nvidia-driver firmware-misc-nonfree
Also ensure that the persistence service is running with sudo systemctl status nvidia-persistenced
.
If your sleep issues persist even after rebooting, and you have made sure you meet the requirements in case of hibernation, you will need to go through system logs to find the culprit. You can make this a little easier with a trick:
sudo dmesg -b > kernel.log &
sudo journalctl -f > journal.log &
sudo systemctl suspend // or hibernate, which ever you are using
If the system encounters an error, reboot it normally and look into the generated kernel.log and journal.log files. They will contain the last few messages that happened between starting the sleep mode and whatever error occurred, omitting most unnecessary chatter from boot/runtime operations.
Keep an eye out for lines containing words like "hibernate" / "hibernation", "suspend", "error" or "power management" / "pm".
If these don't reveal any issues either, try entering sleep with a minimal set of USB devices (unplug everything you can, including keyboard, mouse, thumb drives, headets etc), disabling wake-on-lan or check bios/uefi settings for power-management or sleep related settings.