Power management/Suspend and hibernate - ArchWiki

Jump to content

# Power management/Suspend and hibernate

From ArchWiki
< Power management

Related articles

- systemd
- Power management
- Wakeup triggers
- swap

There are multiple methods of suspending available, notably:

Suspend to idle
  Called S0ix by Intel, Modern Standby (previously "Connected Standby") by Microsoft and S2Idle by the kernel. Designed to be used instead of the S3 sleeping state for supported systems, by providing identical energy savings but a drastically reduced wake-up time.
  Tip While this state is subject to battery drain issues on Windows or macOS since they support waking devices in this state for network activity, the Linux software ecosystem does not currently make use of this feature and should be unaffected.
Suspend to RAM (aka suspend)
  The S3 sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).
Suspend to disk (aka hibernate)
  The S4 sleeping state as defined by ACPI. Saves the machine's state into swap space and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is zero power consumption.
Hybrid suspend (aka hybrid sleep)
  A hybrid of suspending and hibernating, sometimes called suspend to both. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes the default suspend. Therefore, if the battery is not depleted, the system can resume instantly. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.

The kernel provides basic functionality, and some high level interfaces provide tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).

## Kernel interface (swsusp)

Note Although the kernel interface can be used directly, which is faster since no extra userspace handling is performed, it is advisable to use the high level interface. It does a better job by performing additional safety checks, as well as providing pre- and post-suspend hook mechanisms in order to properly set the hardware clock, restore wireless, etc.

It is possible to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to `/sys/power/state` is the primary mechanism to trigger this suspend.

See kernel documentation for details.

## High level interface (systemd)

Note The goal of the high level interface is to provide binaries/scripts that can be invoked to perform suspend/hibernate and ways to hook extra preparatory/cleanup work into the said process. For automatically entering sleep state on power buttons, menu clicks, or laptop lid events, refer to Power management#ACPI events.

systemd provides native commands for suspend, hibernate and a hybrid suspend. This is the default interface used in Arch Linux.

`systemctl suspend` should work out of the box. For `systemctl hibernate` to work on your system you might need to follow the instructions at #Hibernation.

There are also two modes combining suspend and hibernate:

- `systemctl hybrid-sleep` 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.
- `systemctl suspend-then-hibernate` initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with `HibernateDelaySec` in systemd-sleep.conf(5). The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by `SuspendEstimationSec` in systemd-sleep.conf(5), at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension).

Tip systemd v256 supports automatically selecting the most appropriate sleep operation with the new `systemctl sleep` command. By default, `suspend-then-hibernate` is used, and falls back to `suspend` and then `hibernate` if not supported. See systemctl(1) for more information.

See #Sleep hooks for additional information on configuring suspend/hibernate hooks. Also see systemctl(1), systemd-sleep(8), and systemd.special(7).

## Changing suspend method

On systems where S0ix suspension does not provide the same energy savings as the regular S3 sleep, or when conserving energy is preferred to a quick resume time, changing the default suspend method is possible.

Tip S0ix is supposed to provide identical or better energy savings as S3 sleep. See Intel blog posts How to achieve S0ix states in Linux, Linux S0ix Troubleshooting and Idling Efficiently on Linux: A Case Study to check if you can make it work as intended. Users on Intel systems can use S0ixSelftestTool. Users on AMD systems can use amd-debug-tools.

Run the following command to see all suspend methods hardware advertises support for (current method is shown in square brackets[1]):

    $ cat /sys/power/mem_sleep

    [s2idle] shallow deep

Supported sleep states in mem_sleep
mem_sleep string | Sleep State
--- | ---
s2idle | suspend-to-idle
shallow | standby
deep | suspend-to-RAM

If your hardware does not advertise the `deep` sleep status, check first if your UEFI advertises some settings for it, generally under Power or Sleep state or similar wording, with options named Windows 10, Windows and Linux or S3/Modern standby support for S0ix, and Legacy, Linux, Linux S3 or S3 enabled for S3 sleep. Failing that, you can keep using `s2idle`, consider using hibernation or try to patch the DSDT tables (or find a patched version online).

Note This last solution is likely going to cause issues. Manufacturers have stopped fixing bugs with the ACPI S3 state since systems shipping with Windows are encouraged to use "Modern standby" by default; if they have voluntarily not advertised it, it is probably broken in some way.

Confirm that your hardware does not exhibit issues with S3 sleep by testing a few sleep cycles after changing the sleep method:

    # echo deep > /sys/power/mem_sleep

If no issues have been found, you can make the change permanent through the `MemorySleepMode` directive in systemd-sleep.conf(5):

    /etc/systemd/sleep.conf.d/mem-deep.conf

    [Sleep]
    MemorySleepMode=deep

or through the `mem_sleep_default=deep` kernel parameter.

In some opposite situations, faulty firmware advertises support for `deep` sleep, while only `s2idle` is supported. In this case, an alternative method for using `s2idle` is available through the `SuspendState` setting:

    /etc/systemd/sleep.conf.d/freeze.conf

    [Sleep]
    SuspendState=freeze

## Hibernation

In order to use hibernation, you must create a swap partition or file, configure the initramfs so that the resume process will be initiated in early userspace, and specify the location of the swap space in a way that is available to the initramfs, e.g. `HibernateLocation` EFI variable defined by systemd or `resume=` kernel parameter. These three steps are described in detail below.

Note

- See dm-crypt/Swap encryption#With suspend-to-disk support when using encryption.
- linux-hardened does not support hibernation, see FS#63648.
- Enabling kernel lockdown prevents hibernation.
- Hibernating to swap on zram is not supported, even when zram is configured with a backing device on permanent storage. While logind will protect against attempts to hibernate into swap space on zram, as an alternative you can create multiple swap spaces. The memory will be stored into a swap file while another available swap space is reserved for zram. See details in #Maintaining swap file for hibernation with zram.

### About swap partition/file size

Even if your swap partition is smaller than RAM, you still have a good chance of hibernating successfully. See "image_size" in the kernel documentation for information on the `image_size` sysfs(5) pseudo-file.

You may either decrease the value of `/sys/power/image_size` to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. systemd#systemd-tmpfiles - temporary files can be used to make this change persistent:

    /etc/tmpfiles.d/hibernation_image_size.conf

    #    Path                   Mode UID  GID  Age Argument
    w    /sys/power/image_size  -    -    -    -   0

The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[2]

### Configure the initramfs

- When the default systemd-based initramfs (using the `systemd` hook) is used, a resume mechanism is already provided and no further hooks are required.
- When using a busybox-based initramfs, the `resume` hook is required in `/etc/mkinitcpio.conf`. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the `resume` hook must follow the `udev` hook. For example:

      HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems resume fsck)

  Regenerate the initramfs for these changes to take effect.

  Note If stacked storage is used for the swap space (e.g. dm-crypt, RAID or LVM), the final mapped device must be available in the early userspace before the resume process begins. Therefore, the `resume` hook must be placed after hooks like `encrypt` or `lvm2`.

### Pass hibernate location to initramfs

When the system hibernates, the memory image is dumped to the swap space, which also includes the state of mounted file systems. Therefore, the hibernate location must be made available to the initramfs, i.e. before the root file system is mounted for resuming from hibernate to work.

When the system is running on UEFI, systemd-sleep(8) will automatically pick a suitable swap space to hibernate into, and the information of the used swap space is stored in `HibernateLocation` EFI variable. Upon next boot, systemd-hibernate-resume(8) reads the location off the EFI variable and the system resumes. This means the following steps are not necessary unless the system is using legacy BIOS or you want to choose a different swap space from the automatically-selected one.

#### Manually specify hibernate location

The kernel parameter `resume=swap_device` can be used, where swap_device follows the persistent block device naming. For example:

- `resume=UUID=4209c845-f495-4c43-8a03-5363dd433153`
- `resume="PARTLABEL=Swap partition"`
- `resume=/dev/archVolumeGroup/archLogicalVolume` – if swap is on a LVM logical volume (UUID and Label should also work)

Note For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the `resume=` parameter must point to the unlocked/mapped device (which contains the file system with the swap file if one is in use, also see the tip below).

The kernel parameters will only take effect after rebooting. To hibernate right away, obtain the volume's major and minor device numbers from lsblk and echo them in format `major:minor` to `/sys/power/resume`.

For example, if the swap device is `8:3`:

    # echo 8:3 > /sys/power/resume

If using a swap file, additionally follow the procedures in #Acquire swap file offset.

##### Acquire swap file offset

When using a swap file for hibernation, the block device on which the file system lies should be specified in `resume=`, and additionally the physical offset of swap file must be specified through `resume_offset=` kernel parameter. [3]

On file systems other than Btrfs, the value of `resume_offset=` can be obtained by running `filefrag -v swap_file`. The output is in a table format and the required value is in the first row of the `physical_offset` column.

For example:

    # filefrag -v swap_file

    Filesystem type is: ef53
    File size of swap_file is 4294967296 (1048576 blocks of 4096 bytes)
     ext:     logical_offset:        physical_offset: length:   expected: flags:
       0:        0..       0:      38912..     38912:      1:
       1:        1..   22527:      38913..     61439:  22527:             unwritten
       2:    22528..   53247:     899072..    929791:  30720:      61440: unwritten
    ...

In the example the value of `resume_offset=` is the first `38912`.

Alternatively, to directly acquire the offset value:

    # filefrag -v swap_file | awk '$1=="0:" {print substr($4, 1, length($4)-2)}'

For Btrfs, do not try to use the filefrag tool, since the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices.[4] Instead, use the btrfs-inspect-internal(8) command. E.g.:

    # btrfs inspect-internal map-swapfile -r swap_file

    198122980

In this example, the kernel parameter would be `resume_offset=198122980`.

To apply the change immediately (without rebooting), echo the resume offset to `/sys/power/resume_offset`. For example, if the offset is `38912`:

    # echo 38912 > /sys/power/resume_offset

Tip The following command may be used to identify the backing device of the swap file: `findmnt -no UUID -T swap_file`

### Change the image compression algorithm for hibernation

The default compression algorithm is selected based on the compile time option `CONFIG_HIBERNATION_DEF_COMP`, but it can be overridden at boot time and runtime.

Different compression algorithms have different characteristics and hibernation may benefit when it uses any of these algorithms, especially when a secondary algorithm (LZ4) offers better decompression speeds over a default algorithm (LZO), which in turn reduces hibernation image restore time.

You can override the default algorithm in two ways:

1) Passing `hibernate.compressor` as a kernel parameter:

    hibernate.compressor=lzo
    hibernate.compressor=lz4

2) Specifying the algorithm at runtime:

    # echo lzo > /sys/module/hibernate/parameters/compressor
    # echo lz4 > /sys/module/hibernate/parameters/compressor

Currently `lzo` and `lz4` are the supported algorithms with LZO being the default.

### Maintaining swap file for hibernation with zram

Tip Instead of the following setup which involves multiple swap spaces, zswap can be used to establish a similar behavior.

It is possible to solve the hibernation problem with zram RAM-only swap by maintaining two or more swap spaces at the same time. systemd will always ignore zram block devices before triggering hibernation [5], therefore keeping both spaces enabled should work without further intervention.

After configuring the swap file, follow the zram page. Make sure zram has the higher swap priority (e.g. `pri=100`).

Note

- Do not create an on-demand swap unit for hibernation as it is not officially supported. See systemd issues #16708 and #30083.
- The kernel alone is responsible for reclaiming anonymous memory of pages and swapping them; not using a swap space can actually lead to bad memory usage. The user can manage priorities in reclaiming memory for certain applications in the form of `memory.low`, tunable by control groups. Overall this is more effective than setting the swappiness parameter.
- Read the Swap Management in kernel documentation and the Chris Down's article - In defence of swap: common misconceptions for more details.

### Hibernation into a thinly-provisioned LVM volume

Hibernation into a thinly-provisioned LVM volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see FS#50703.

You can fully allocate the LVM volume by simply filling it with zeros. E.g.:

    # dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress

To verify the volume is fully allocated, you can use:

    # lvs

      LV                   VG  Attr       LSize   Pool Origin    Data%  Meta%  Move Log Cpy%Sync Convert
      swap                 vg0 Vwi-aot--- 10.00g  pool           100

A fully allocated volume will show up as having 100% data usage.

Warning Do not use TRIM on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use `discard` in `/etc/fstab` and the `-d`/`--discard` option of swapon. Otherwise the used space will be deallocated.

### Disable zswap writeback to use the swap space only for hibernation

zswap has a per-cgroup option to disable writeback. Since there is no global option to disable zswap writeback, you need to use the systemd unit setting `MemoryZSwapWriteback` (see systemd.resource-control(5) § Memory Accounting and Control) in all possible unit types. This allows to use zswap just like zram with the added benefit of supporting hibernation.

To avoid having to manually create twelve top level per-type drop-in files (for system and user `scope`, `service`, `slice`, `socket`, `mount`, `swap` units types), install zswap-disable-writebackAUR. Enable zswap and reboot for the settings to take effect.

Try to perform memory intensive tasks and confirm that zswap has not written anything to disk:

    # cat /sys/kernel/debug/zswap/written_back_pages

    0

## Sleep hooks

### Custom systemd units

systemd starts `suspend.target`, `hibernate.target`, `hybrid-sleep.target`, or `suspend-then-hibernate.target` for each sleep state, respectively. All the aforementioned targets pull in `sleep.target`. Any of the targets can be used to invoke custom units before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. Examples:

    /etc/systemd/system/user-suspend@.service

    [Unit]
    Description=User suspend actions
    Before=sleep.target

    [Service]
    User=%I
    Type=forking
    Environment=DISPLAY=:0
    ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop
    ExecStart=/usr/bin/sflock
    ExecStartPost=/usr/bin/sleep 1

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/user-resume@.service

    [Unit]
    Description=User resume actions
    After=suspend.target hibernate.target

    [Service]
    User=%I
    Type=simple
    ExecStart=/usr/local/bin/ssh-connect.sh

    [Install]
    WantedBy=suspend.target hibernate.target

Enable `user-suspend@user.service` and/or `user-resume@user.service` for the change to take effect.

Note As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via `ExecStartPost=/usr/bin/sleep 1` helps prevent this.

For root/system actions:

    /etc/systemd/system/root-suspend.service

    [Unit]
    Description=Local system suspend actions
    Before=sleep.target

    [Service]
    Type=simple
    ExecStart=-/usr/bin/pkill sshfs

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/root-resume.service

    [Unit]
    Description=Local system resume actions
    After=suspend.target hibernate.target

    [Service]
    Type=simple
    ExecStart=/usr/bin/systemctl restart mnt-media.automount

    [Install]
    WantedBy=suspend.target hibernate.target

#### Combined sleep/resume unit

With the combined unit file, a single hook does all the work for different phases (sleep/resume) and for different targets.

Example and explanation:

    /etc/systemd/system/wicd-sleep.service

    [Unit]
    Description=Wicd sleep hook
    Before=sleep.target
    StopWhenUnneeded=yes

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=-/usr/share/wicd/daemon/suspend.py
    ExecStop=-/usr/share/wicd/daemon/autoconnect.py

    [Install]
    WantedBy=sleep.target

- `RemainAfterExit=yes`: After started, the service is considered active until it is explicitly stopped.
- `StopWhenUnneeded=yes`: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after `sleep.target` is stopped.
- Because `sleep.target` has `StopWhenUnneeded=yes`, the hook is guaranteed to start/stop properly for different tasks.

### Hooks in /usr/lib/systemd/system-sleep

Note This method is considered a hack by systemd according to systemd-sleep(8). systemd-sleep will run these hooks concurrently rather than one after another. For a more well-defined interface with support for ordering, see #Custom systemd units.

systemd-sleep runs all executables in `/usr/lib/systemd/system-sleep/`, passing two arguments to each of them:

1. Either `pre` or `post`, depending on whether the machine is going to sleep or waking up.
2. `suspend`, `hibernate`, `hybrid-sleep` or `suspend-then-hibernate`, depending on which is being invoked.

An environment variable called `SYSTEMD_SLEEP_ACTION` will be set and contain the sleep action that is processing. This is primarily helpful for suspend-then-hibernate where the value of the variable will be `suspend`, `hibernate`, or `suspend-after-failed-hibernate` in cases where hibernation has failed.

The output of any custom script will be logged by systemd-suspend.service, systemd-hibernate.service or systemd-hybrid-sleep.service. You can see its output in systemd's journalctl:

    # journalctl -b -u systemd-suspend.service

An example of a custom sleep script:

    /usr/lib/systemd/system-sleep/example.sh

    #!/bin/sh
    case $1/$2 in
      pre/*)
        echo "Going to $2..."
        ;;
      post/*)
        echo "Waking up from $2..."
        ;;
    esac

Do not forget to make your script executable.

## Tips and tricks

### Unlocking automatically on resume in trusted locations

When resuming, you can automatically unlock your system if it is connected to certain devices or trusted Wi-Fi networks.

    /etc/local-scripts/resume-unlock.sh

    #!/usr/bin/bash
    # Unlock session if at a trusted location

    function trusted() {
        # Check if connected to a trusted Wi-Fi network
        [[ $(iwgetid -r) == your_home_ssid ]] \
            && return 0

        # Check if trusted USB device is connected.
        #lsusb -d xxxx:xxxx && return 0

        return 1 # Not trusted
    }

    for (( i=0; i < 10; i++ )); do
        if trusted; then
            loginctl unlock-sessions
            exit
        fi
        sleep 0.5
    done

Configure your desktop environment so that it locks on resume, and then create a sleep hook that runs the above script after resuming. You also need to install wireless_tools to read the connected Wi-Fi SSID. If you also want to test for connected USB devices, uncomment the `lsusb -d ...` line in the script and fill in the ID of your trusted device. You can get the ID of your device by running `lsusb`.

### Disable sleep completely

When using a device such as a server, suspending/hibernating might not be needed or it could even be undesired. Each sleep state can be disabled through systemd-sleep.conf(5):

    /etc/systemd/sleep.conf.d/disable-sleep.conf

    [Sleep]
    AllowSuspend=no
    AllowHibernation=no
    AllowHybridSleep=no
    AllowSuspendThenHibernate=no

Additionally (and alternatively for desktop users), it is also possible to mask the following units (such as to hide buttons in user interfaces):

    hibernate.target hybrid-sleep.target sleep.target suspend-then-hibernate.target suspend.target

### Intel Rapid Start Technology (IRST)

Intel Rapid Start Technology is a firmware method of hibernation that allows hibernating from sleep after a predefined interval or according to battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware, and the firmware also provides support for setting the duration after suspend/battery event triggering hibernation. However, some devices–despite supporting IRST in the firmware–only allow it to be configured via Intel's Windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under Linux.

With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "a few seconds longer than resuming from S3 but is far faster than resuming from hibernation".

Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may have a pre-existing IRST partition which can be retained during the Arch Linux installation process (rather than wiping and re-partitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.

Warning The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[6]

If you intend to wipe and re-partition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to GUID `D3BFE2DE-3DAF-11DF-BA40-E3A556D89593` for a GPT partition or ID `0x84` for an MBR partition. You may also need to enable support for IRST in your system's firmware settings.

Tip The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.

The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependent on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.

Configuring IRST hibernation events in the Linux kernel requires `CONFIG_INTEL_RST` built-in or as a module. Once loaded via `modprobe intel_rst`, it should create the files `wakeup_events` and `wakeup_time` under `/sys/bus/acpi/drivers/intel_rapid_start/*/` that can be used for further configuration. This module is tersely documented, see the source drivers/platform/x86/intel/rst.c for more details.

See also the general Q&A and user guides for Intel Rapid Start Technology.

### Track laptop battery energy change during sleep states

To measure power consumption in suspend states use Batenergy script to log battery changes to the system journal. This allows to compare power consumption in S3 / S0x states or check after BIOS and kernel updates for regressions and fixes. The script needs bc to be installed for calculation.

## Troubleshooting

Debugging suspend issues is particularly difficult, since the screen (including the consoles) gets blanked out, and force-rebooting a hung system may fail to flush the journal to disk, even when using SysRq.

The blog article Best practices to debug suspend issues lists some steps (in section 2) that can help troubleshooting.

### Failure to suspend due to USB device

If the following kernel error appears in the journal:

    PM: Some devices failed to suspend, or early wake event detected

...then look for a line like this nearby:

    xhci_hcd 0000:02:00.0: PM: failed to suspend async: error -16

lspci(1) may give you more information on the failing device:

    $ lspci -s 02:00.0

    02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 500 Series Chipset USB 3.1 XHCI Controller

Try disconnecting devices on that port.

### Instantaneous wakeup after suspending

See Wakeup triggers#Instantaneous wakeup after suspending.

If the system seems to wake up immediately after attempting to hibernate, check out #System wakes up immediately after hibernating below.

### Hibernation-specific

Hibernation is particularly finicky, involving many moving parts (systemd-logind, system logic, the boot loader, initramfs hooks...). Note also that the journal may become scrambled (entries out of order, wrong timestamps) right before and/or right after hibernation, due to systemd-journald being interrupted by the hibernation process and having to catch up.

Difficulties entering hibernation may be diagnosed more easily by adding debug logging to `systemd-logind.service` (responsible for some pre-hibernation sanity checks) and/or `systemd-sleep.service` (responsible for setting up hibernation parameters), which then emit debug messages to the journal.

#### Call to Hibernate / HybridSleep / SuspendThenHibernate failed

If `systemctl hibernate` (or equivalent) fails with such a message, it means that systemd-logind has refused to enter hibernation. Consider adding debug logging to `systemd-logind.service`, as described above.

While it is possible to bypass systemd-logind and invoke the underlying sleep targets directly, this skips several sanity checks and is likely a bad idea.

##### No such file or directory

Before executing a hibernation-related command, systemd-logind is made to check if there is enough swap. However, it cannot access files under `/home`, `/root`, or `/run/user` (systemd.exec(5) § ProtectHome=yes), and thus if any active swap files are located under any of those directories, logind's check will fail and generate the above error.

The best fix is to avoid swap files under those directories:

    # swapoff /home/user/swap
    # rm /home/user/swap

Create a new swap file in a supported location and then edit the fstab or the corresponding swap unit file.

However, if the swap file must absolutely be kept there, workarounds exist at some cost:

- Disable (with `swapoff`) the offending swap files before hibernating.
- The security of `systemd-logind.service` can be weakened by editing it to contain `ProtectHome=read-only` instead (and possibly re-build some of the sandbox using `InaccessiblePaths=`).
- The problematic hibernation size check can be disabled entirely by passing the `SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1` environment variable to systemd-logind, for example by editing `systemd-logind.service` to add `Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1`.
  Beware that this can cause the system to attempt to hibernate and fail.

##### Specified resume device is missing or is not an active swap device

This occurs when systemd-logind cannot find the hibernation target specified in `/sys/power/resume` and `/sys/power/resume_offset`.[7] (It does so in case those were filled in manually beforehand, but they are also automatically filled in as part of the hibernation resuming process.)

If you have intentionally specified those manually, make sure that the target partition and/or swap file is accessible (mounted and/or enabled).

Otherwise, write `0:0` to `/sys/power/resume` and `0` to `/sys/power/resume_offset` to clear them, and try again. (Rebooting also clears those, unless the `resume=` and/or `resume_offset=` kernel parameters are used.)

#### System wakes up immediately after hibernating

Beyond the issues described in Wakeup triggers#Instantaneous wakeup after suspending, it is possible for hibernation to appear to succeed, only to end immediately. Check if the journal contains a `Failed to put system to sleep. System resumed again` line emitted by systemd-sleep: they mean that not enough free swap space was available.

Look nearby for kernel logs like these:

    kernel: PM: hibernation: Normal pages needed: 999287 + 1024, available pages: 916116
    kernel: PM: hibernation: Not enough free memory
    kernel: PM: hibernation: Error -12 creating image

Tip

- You can multiply a number of pages by the output of `getconf PAGE_SIZE` to get a number of bytes.
- errno(1) can give a description of the error itself, here `12`.

Note that the kernel needs to perform its allocation in a single swap space; thus, if `swapon --show` shows that free space is distributed across several swaps, consider briefly disabling one swap to consolidate their usage, and trying again.

Tweaking swap priority can help keep one swap device mostly empty for hibernation.

#### Wake-on-LAN

If Wake-on-LAN is active, the network interface card will consume power even if the computer is hibernated.

#### System does not power off when hibernating

When you hibernate your system, the system should power off (after saving the state on the disk). On some firmware the S4 sleeping state does not work reliably. For example, instead of powering off, the system might reboot or stay on but unresponsive. If that happens, it might be instructive to set the `HibernateMode` to `shutdown` in sleep.conf.d(5):

    /etc/systemd/sleep.conf.d/hibernatemode.conf

    [Sleep]
    HibernateMode=shutdown

With the above configuration, if everything else is set up correctly, on invocation of a `systemctl hibernate` the machine will shut down, saving state to disk as it does so.

#### Operating system not found (or wrong OS booting) when booting after hibernation

This can happen when the boot disk is an external disk, and seems to be caused by a BIOS/firmware limitation. The BIOS/firmware tries to boot from an internal disk, while hibernation was done from an OS on an external (or other) disk.

Set `HibernateMode=shutdown` as shown in #System does not power off when hibernating to solve the problem permanently. If you have already locked yourself out, you can try rebooting your system 4 times (wait for the error to appear each time), which on some BIOS'es forces a normal boot procedure.

#### Hibernation and multi boot systems

If you are running a multi boot system (including but not limited to dual boot with Windows) and want to be able to boot into your other system while your main Arch Linux is hibernated, you must take extra caution not to mount filesystems that are still in use by the hibernated system. Before attempting to mount such filesystem within another system, you must make sure to unmount this filesystem before hibernating the system. This can be achieved with sleep hooks.

This issue is particularly relevant for the EFI system partition, because the ESP is expected to be shared across multiple systems. Check the matching section in EFI system partition for mitigation strategies, which can be adapted to other filesystems as well.

#### Hardware watchdog

A problem may arise when using the hardware watchdog timer (disabled by default, see `RuntimeWatchdogSec=` in systemd-system.conf(5) § OPTIONS). A buggy watchdog timer may reset the computer before the system finishes creating the hibernation image.

#### Black/blank screen on resuming

Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES, removing the `kms` hook, and then regenerating the initramfs can possibly solve this issue, in particular with graphics drivers for early KMS. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM.

Moving from the ATI video driver to the newer AMDGPU driver could also help to make the hibernation and awakening process successful.

### Blank/black screen after suspend/hibernate

Suspending and hibernation are delicate tasks, requiring system and device state to be preserved while they are powered off. Bugs can be introduced by updates, especially of the kernel; if breakage occurs after an upgrade, consider downgrading the kernel or switching to linux-lts, and seeing if that fixes the issue.

With NVIDIA cards, the VRAM contents are saved to disk when suspending.[8] Make sure that you have enough disk space, otherwise you might get a blank screen when resuming. Another cause for this could be fixed by blacklisting the module `nvidiafb`. [9]

### Touchpad causes a kernel panic on resume

Laptops with an Intel CPU that load the `intel_lpss_pci` kernel module for a touchpad may face kernel panic on resume (blinking caps lock) [10]. The module needs to be added to the initramfs, e.g.:

    /etc/mkinitcpio.conf

    MODULES=(... intel_lpss_pci ...)

Then regenerate the initramfs.

### PC will not wake from sleep on A520I and B550I motherboards

On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD microcode package is installed.

Verify the line starting with `GPP0` has the enabled status:

    $ cat /proc/acpi/wakeup

    Device	S-state	  Status   Sysfs node
    GP12	  S4	*enabled   pci:0000:00:07.1
    GP13	  S4	*enabled   pci:0000:00:08.1
    XHC0	  S4	*enabled   pci:0000:0b:00.3
    GP30	  S4	*disabled
    GP31	  S4	*disabled
    PS2K	  S3	*disabled
    GPP0	  S4	*enabled   pci:0000:00:01.1
    GPP8	  S4	*enabled   pci:0000:00:03.1
    PTXH	  S4	*enabled   pci:0000:05:00.0
    PT20	  S4	*disabled
    PT24	  S4	*disabled
    PT26	  S4	*disabled
    PT27	  S4	*disabled
    PT28	  S4	*enabled   pci:0000:06:08.0
    PT29	  S4	*enabled   pci:0000:06:09.0

If that is enabled, you can run the following command to disable it:

    # echo GPP0 > /proc/acpi/wakeup

Now test by running `systemctl suspend` and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. Create a systemd unit file:

    /etc/systemd/system/toggle-gpp0-to-fix-wakeup.service

    [Unit]
    Description="Disable GPP0 to fix suspend issue"

    [Service]
    ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"

    [Install]
    WantedBy=multi-user.target

Do a daemon-reload and start/enable the newly created unit.

Alternatively, you can create a udev rule. Assuming `GPP0`’s sysfs node is `pci:0000:00:01.1` like in the example, run `udevadm info -a -p /sys/bus/pci/devices/0000\:00\:01.1` to get the relevant information and create a udev rule like this one:

    /etc/udev/rules.d/10-gpp0-acpi-fix.rules

    KERNEL=="0000:00:01.1", SUBSYSTEM=="pci", DRIVERS=="pcieport", ATTR{vendor}=="0x1022", ATTR{device}=="0x1483", ATTR{power/wakeup}="disabled"

The udev daemon is already watching for changes in your system by default. If needed you can reload the rules manually.

### Suspend from corresponding laptop Fn key not working

If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [11] Do:

    # journalctl --grep="Watching system buttons"

You might see something like this:

    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)

Notice no keyboard device. List keyboard devices as follows:

    $ stat -c%N /dev/input/by-id/*-kbd

    ...
    /dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd -> ../event6
    ...

Now obtain `ATTRS{name}` for the parent keyboard device [12]. As an example, on the above list this keyboard device has `event6` as device input event, it can be used to search its respective attribute name:

    # udevadm info -a /dev/input/event6

    ...
    KERNEL=="event6"
    ...
    ATTRS{name}=="SIGMACHIP USB Keyboard"

Now write a custom udev rule to add the "power-switch" tag:

    /etc/udev/rules.d/70-power-switch-my.rules

    ACTION=="remove", GOTO="power_switch_my_end"
    SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="SIGMACHIP USB Keyboard", TAG+="power-switch"
    LABEL="power_switch_my_end"

After reloading the udev rules and restarting `systemd-logind.service`, you should see `Watching system buttons on /dev/input/event6` in the journal of logind.

### System freezes for 60 seconds and then wakes back up or hangs after waking up

Since systemd v256, systemd freezes `user.slice` before sleeping. This process can fail due to kernel bugs, particularly when KVM is in use.[13][14]

Messages in the logs will contain `Failed to freeze unit 'user.slice'` before sleep. When such an issue occurs, trying to login (start another session) would fail with:

    pam_systemd(process:session): Failed to create session: Job 9876 for unit 'session-6.scope' failed with 'frozen'

To temporarily revert back to the old behavior, edit `systemd-suspend.service`, `systemd-hibernate.service`, `systemd-hybrid-sleep.service`, and `systemd-suspend-then-hibernate.service` with the following drop-in:

    [Service]
    Environment=SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false

However, this drop-in can itself prevent the system from going to sleep.[15]

Category:

- Power management

Power management/Suspend and hibernate
Add topic