LinuxCommandLibrary

systemctl-hybrid-sleep

Enter system hybrid sleep

TLDR

Put the system into hybrid sleep immediately

$ systemctl hybrid-sleep
copy

Force hybrid sleep even if inhibitors are present
$ systemctl hybrid-sleep --force
copy

Put the system into hybrid sleep without sending a wall message to logged-in users
$ systemctl hybrid-sleep --no-wall
copy

SYNOPSIS

systemctl OPTIONS... hybrid-sleep

PARAMETERS

--no-block
    Do not wait for the operation to complete. The command returns immediately after sending the request to systemd, allowing subsequent commands to run without delay.

-f, --force
    Force the operation. When used with suspend, hibernate, or hybrid-sleep, this option can bypass certain checks or inhibitions that might otherwise prevent the system from entering the desired power state. Use with caution as it might override safety mechanisms.

DESCRIPTION

The systemctl hybrid-sleep command initiates a hybrid suspend operation on the Linux system. This unique power-saving state combines the benefits of both traditional suspend-to-RAM (sleep) and suspend-to-disk (hibernate). When hybrid-sleep is invoked, the system first writes its current state (RAM contents) to a swap partition or file, similar to hibernation. Concurrently, or immediately after, it enters a low-power suspend-to-RAM state.

The primary advantage of this approach is resilience against power loss. If power remains, the system can wake up quickly from RAM, just like a regular suspend. However, if power is interrupted (e.g., battery depletion), the system can still resume its previous state from the data saved on disk once power is restored. This provides a robust solution for laptops and critical systems where both quick resume and data integrity are important. Proper configuration, including sufficient swap space, is crucial for hybrid-sleep to function correctly.

CAVEATS

Caveats and Limitations:
1. Swap Space Requirement: Requires sufficient swap space or a dedicated swap partition at least as large as the system's RAM for the suspend-to-disk portion.
2. Hardware/Driver Support: Not all hardware or drivers might fully support hybrid sleep, potentially leading to issues with resuming or unstable behavior.
3. Initial Suspend Time: The initial process of saving state to disk can take longer than a simple suspend-to-RAM.
4. Resume Time Variability: Resume time can vary; if resuming from RAM, it's fast; if from disk after power loss, it's slower (similar to a full hibernate).
5. Data Integrity: Ensure all necessary services and applications handle system state changes gracefully to avoid data corruption.

HOW IT WORKS WITH SYSTEMD TARGETS

When systemctl hybrid-sleep is executed, systemd activates the hybrid-sleep.target. This target pulls in systemd-suspend-hybrid.service, which is responsible for coordinating the actual suspend-to-disk and suspend-to-RAM operations. Before entering the low-power state, systemd executes all services configured to run before sleep.target (via Before=sleep.target or Requires=sleep.target). After resuming, services configured to run after sleep.target are executed, ensuring a smooth transition back to the active state and proper re-initialization of system components.

HISTORY

The concept of hybrid sleep predates systemd, often implemented through custom scripts or pm-utils in older Linux systems. With the widespread adoption of systemd as the default init system in many Linux distributions, systemctl became the standard interface for managing system power states. The hybrid-sleep verb was introduced as part of systemd's integrated power management, simplifying its invocation and integrating it with systemd's robust service and target management model.

SEE ALSO

systemctl(1), systemctl suspend(1), systemctl hibernate(1), systemd-sleep.service(8), hybrid-sleep.target(8)

Copied to clipboard