systemctl-suspend-then-hibernate

Suspend the system and hibernate after the configured delay

$ systemctl suspend-then-hibernate

$ systemctl suspend-then-hibernate --force

systemctl suspend-then-hibernate

No direct parameters
    The suspend-then-hibernate action itself does not accept direct command-line parameters. Its behavior is entirely configured through the systemd-sleep.conf file. However, standard systemctl options like --no-block (to return immediately without waiting for the operation to complete) or --quiet (to suppress output) can precede the action, affecting how systemctl itself executes the command.

The systemctl suspend-then-hibernate command initiates a power-saving mode where the system first enters suspend-to-RAM (sleep) state. In this state, the system consumes minimal power, and its state is preserved in volatile memory (RAM), allowing for a quick resume. However, if the system remains suspended for a predefined duration, it will automatically transition into a hibernate-to-disk state. During hibernation, the system's entire state, including all open applications and data, is saved to a persistent storage device (typically swap space on a hard drive or SSD), and the system is then powered off completely.

This hybrid approach combines the benefits of both suspend and hibernate: the speed of suspend for short periods of inactivity, and the energy efficiency and data safety of hibernate for longer, unattended periods, or in case of battery depletion. It prevents data loss due to power failure during an extended suspend and ensures zero power consumption when finally hibernated. The transition delay from suspend to hibernate is configurable via the SuspendThenHibernateDelay option in the systemd-sleep.conf file.

Swap Space Requirement: For the hibernation phase to function correctly, your system must have a swap partition or file that is at least as large as your installed RAM. Without sufficient swap space, the system will fail to hibernate.
Configuration: The behavior of this mode, especially the crucial delay before hibernating, is controlled by settings in /etc/systemd/sleep.conf or custom configuration files located in /etc/systemd/sleep.conf.d/. Incorrect or missing configuration can lead to unexpected behavior or failure to transition to hibernate.
Hardware/Kernel Support: Both suspend and hibernate states require proper kernel and hardware support. Issues with display drivers, power management interfaces (ACPI), or specific hardware components can prevent these states from working reliably.
Data Loss during Suspend: While the ultimate goal is to save state, if power is completely lost during the initial suspend-to-RAM phase (before the system has a chance to automatically hibernate), any unsaved work will be lost. The hibernation step acts as a safeguard against prolonged power loss, but not instantaneous unexpected power cuts during the suspend phase.

The primary configuration for suspend-then-hibernate is managed through /etc/systemd/sleep.conf or supplementary configuration files within /etc/systemd/sleep.conf.d/. Key options to set in the [Sleep] section include:

• SuspendThenHibernate=yes: Explicitly enables this power-saving mode.
• SuspendThenHibernateDelay=duration: This is the most critical setting, defining the time (e.g., '2h' for 2 hours, '30min' for 30 minutes, '1800s' for 30 minutes) the system will wait in suspend-to-RAM state before automatically transitioning to hibernate-to-disk.
• SuspendState=state: Specifies the method for suspending to RAM (e.g., 'mem' is the most common and generally recommended).
• HibernateState=state: Specifies the method for hibernating to disk (e.g., 'disk' is typical).

When systemctl suspend-then-hibernate is executed, the following sequence of events unfolds:
1. The system immediately enters a suspend-to-RAM state, effectively 'sleeping' with its state preserved in memory and drawing minimal power.
2. A timer is initiated for the duration specified by the SuspendThenHibernateDelay option.
3. If the system is woken up (e.g., by keyboard, mouse, or power button) before this timer expires, it resumes quickly from RAM, and the suspend-then-hibernate cycle is effectively reset.
4. If the timer expires without the system being woken, the system automatically transitions from suspend-to-RAM to hibernate-to-disk. This involves saving the entire system state to swap space and then powering off completely.
5. Once hibernated, the system consumes no power. Upon the next power-on, the system restores its state from disk, allowing the user to resume exactly where they left off before the hibernation process began.

With the widespread adoption of systemd as the default init system in most major Linux distributions, its integrated power management capabilities have largely superseded older utilities like pm-utils. The suspend-then-hibernate target was introduced as part of systemd's comprehensive power management features to provide a robust and configurable solution for hybrid power saving. It addresses a common user desire to combine the rapid wake-up of suspend with the power efficiency and data protection of hibernate, offering a more intelligent and reliable approach to system sleep states within the systemd ecosystem.

systemctl(1), systemctl suspend(1), systemctl hibernate(1), systemctl hybrid-sleep(1), systemd-sleep.conf(5), pm-suspend(8), pm-hibernate(8)