How to Completely Disable the ‘systemd-suspend-then-hibernate’ Service in Ubuntu Server

In Ubuntu Server and other systemd-based Linux distributions, systemd-suspend-then-hibernate.service is an advanced, hybrid power management daemon designed to execute a delayed, two-stage ACPI transition. When invoked, it first suspends the machine to RAM (S3). A pre-configured wake alarm (RTC timer) is then set; if the system is not woken up before the timer expires, the hardware briefly wakes up, writes the entire RAM contents to the swap partition (S4), and physically powers off. While excellent for maximizing battery life on idle laptops, this dynamic state-shifting introduces a catastrophic availability, I/O latency, and network partition liability in headless server environments, highly available clusters, or immutable infrastructure deployments. Allowing a server to spontaneously transition between S3 and S4 based on an RTC timer guarantees dropped database transactions and breached SLA uptimes.

This guide explains how to completely disable the systemd-suspend-then-hibernate service in Ubuntu Server, enforcing an absolute block on this delayed sleep state and ensuring the server’s uptime remains strictly uninterrupted.

Stop and Mask the systemd-suspend-then-hibernate Service

Because this delayed transition is deeply integrated into the systemd-logind power management framework and can be invoked dynamically by various targets or idle timeout events, a simple configuration tweak (like modifying systemd-sleep.conf) is insufficient to guarantee the kernel will never transition to this state. To enforce an absolute cryptographic block, we must explicitly mask the unit.

  1. Log into your Ubuntu Server via SSH using an account with sudo privileges.
  2. Stop the service to clear any active processes (though it generally only runs momentarily during state transitions):
    sudo systemctl stop systemd-suspend-then-hibernate.service
  3. For absolute certainty, explicitly mask the service unit. This symlinks the unit file to /dev/null, creating a hard cryptographic block against it being invoked dynamically by RTC alarms, dbus messages, or manual user commands:
    sudo systemctl mask systemd-suspend-then-hibernate.service
  4. Optional but recommended: To guarantee that the parent target cannot be reached either, mask the associated target unit:
    sudo systemctl mask suspend-then-hibernate.target

Verify the Service Lockdown

By masking the service and its target, you guarantee that systemd will completely reject any attempt to transition the host hardware into this delayed, two-stage ACPI sleep sequence, optimizing the OS strictly for always-on server operations.

To verify the lockdown is successful, attempt to start the service manually:

sudo systemctl start systemd-suspend-then-hibernate.service

Systemd will return a fatal error stating that the unit is masked (e.g., Failed to start systemd-suspend-then-hibernate.service: Unit systemd-suspend-then-hibernate.service is masked). Furthermore, running systemctl status systemd-suspend-then-hibernate.service will show the service state as masked. The server’s ACPI power management pipeline is now strictly secured against automated hibernation timers.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.