Configuring sleep and hibernate on linux debian

Table of contents

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 both suspend and hibernate 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 normal suspend mode, but waking up periodically to check battery state. When battery charge becomes really low (typically around 5%), puts the system into hibernate 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.

More articles

Automating RKE2 kubernetes installation with ansible

Effortless production cluster setups anywhere

Switching from docker to podman

Embracing modern and standardized container management

Writing a pastebin application in bash

You don't always need a heavy web framework