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).
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 is the primary mechanism to trigger this suspend.
See kernel documentation for details.
systemd provides native commands for suspend, hibernate and a hybrid suspend. This is the default interface used in Arch Linux.
should work out of the box. For to work on your system you might need to follow the instructions at #Hibernation.
There are also two modes combining suspend and hibernate:
See #Sleep hooks for additional information on configuring suspend/hibernate hooks. Also see systemctl(1), systemd-sleep(8), and systemd.special(7).
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.
Run the following command to see all suspend methods hardware advertises support for (current method is shown in square brackets[1]):
If your hardware does not advertise the 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 , consider using hibernation or try to patch the DSDT tables (or find a patched version online).
Confirm that your hardware does not exhibit issues with S3 sleep by testing a few sleep cycles after changing the sleep method:
You may either decrease the value of 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:
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]
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.
If using a swap file, additionally follow the procedures in #Acquire swap file offset.
Alternatively, to directly acquire the offset value:
Starting with Linux 6.9[5], the image compression algorithm for hibernation can be changed. The default compression algorithm is selected based on the compile time option , 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:
Currently and are the supported algorithms with LZO being the default.
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 [6], 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. ).
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.:
To verify the volume is fully allocated, you can use:
A fully allocated volume will show up as having 100% data usage.
In Linux 6.8, zswap gained a per-cgroup option to disable writeback. By using systemd unit setting (see systemd.resource-control(5) § Memory Accounting and Control) in all possible unit types, zswap writeback can be effectively disabled entirely. 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 , , , , , units types), install zswap-disable-writeback. 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:
With the combined unit file, a single hook does all the work for different phases (sleep/resume) and for different targets.
When resuming, you can automatically unlock your system if it is connected to certain devices or trusted Wi-Fi networks.
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 line in the script and fill in the ID of your trusted device. You can get the ID of your device by running .
When using a device as e.g 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):
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.
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 for a GPT partition or ID for an MBR partition. You may also need to enable support for IRST in your 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.
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.
You might want to tweak your DSDT table to make it work. See DSDT.
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.
A problem may arise when using the hardware watchdog timer (disabled by default, see in systemd-system.conf(5) § OPTIONS). A buggy watchdog timer may reset the computer before the system finishes creating the hibernation image.
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES, removing the hook and rebuilding 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. Also, check the blog article best practices to debug suspend issues.
System may fail to suspend because of a USB device. You might see the following error:
If Wake-on-LAN is active, the network interface card will consume power even if the computer is hibernated.
See Wakeup triggers#Instantaneous wakeup after suspending.
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 to in sleep.conf.d(5):
With the above configuration, if everything else is set up correctly, on invocation of a the machine will shut down, saving state to disk as it does so.
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 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.
If the swap file is in , systemd-logind will not be able to access it, giving the warning message and resulting in a need for authentication on . This setup should be avoided, as it is considered unsupported upstream. See systemd issue 15354 for two workarounds.
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 has the enabled status:
If that is enabled, you can run the following command to disable it:
The udev daemon is already watching for changes in your system by default. If needed you can reload the rules manually.
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. [10] Do:
You might see something like this:
Notice no keyboard device. List keyboard devices as follows:
Now obtain for the parent keyboard device [11]. As an example, on the above list this keyboard device has as device input event, it can be used to search its respective attribute name:
Now write a custom udev rule to add the "power-switch" tag:
Messages in the logs will contain before sleep. When such an issue occurs, trying to login (start another session) would fail with:
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.