Home / Alt manpages / systemd-suspend.service(8)

  • systemd-suspend.service(8)
  • Admin command
  • linux

Choose and Test systemd Sleep Modes Safely

Suspend, hibernate, hybrid sleep or suspend-then-hibernate: systemd-suspend.service and its siblings decide which one runs on your machine. You will finish with a checked configuration, a deliberate choice of mode, and a reversible local override. The examples match the installed systemd 255.4-1ubuntu8.17 package.

Allow about fifteen minutes, plus the time for one planned sleep and resume test. You need a shell and sudo for the configuration step. Reading the current state is unprivileged; actually entering a sleep state is service-disrupting and should only happen when you are at the machine or have a tested remote recovery path.

1. Confirm the installed interface

Start by checking the package and helper version. Neither command changes power state:

$ dpkg-query -W -f='${Package} ${Version}\n' systemd
systemd 255.4-1ubuntu8.17
$ systemd-sleep --version
systemd 255.4 (255.4-1ubuntu8.17)

The exact version string can differ after an update; treat the local manpages as the authority for this installation. The four service units are wrappers around /usr/lib/systemd/systemd-sleep. Do not call their service files directly.

Checkpoint

Inspect the unit mapping before changing anything:

$ systemctl cat systemd-suspend.service systemd-hibernate.service \
    systemd-hybrid-sleep.service systemd-suspend-then-hibernate.service

Each unit should show an ExecStart line invoking systemd-sleep with the matching action. If a vendor or local override changes that mapping, stop and review it before trusting the rest of this guide.

2. Check which kernel states you actually have

The kernel publishes available suspend states in /sys/power/state and hibernation modes in /sys/power/disk. Both are readable as an ordinary user:

$ cat /sys/power/state
freeze mem
$ cat /sys/power/disk
[platform] shutdown reboot suspend

The bracketed item in the second output is the current hibernation mode. Your output is hardware and kernel dependent, so do not copy freeze, mem, platform or any other value into a config file until you have seen it appear here first.

Safety boundary

These files describe capabilities; writing to them changes power state. Do not test that by redirecting into them yourself. Let systemd run the appropriate service instead.

3. Choose the sleep action

Pick the mode that matches the failure you actually want to tolerate:

  • suspend pauses execution in a low-power state held in RAM. Quick, but a complete power loss can lose the suspended session.
  • hibernate writes the session to hibernation storage before powering down. Slower, but a complete power loss should not lose it if hibernation is correctly configured.
  • hybrid-sleep saves a hibernation image and then suspends. Fast normal wake, with a recovery path after power loss.
  • suspend-then-hibernate suspends first, then wakes and hibernates after a delay or an earlier low-battery condition.

Trigger an action through systemctl, never by invoking systemd-suspend.service or systemd-sleep directly:

$ systemctl suspend
# or, when the saved session and power-loss behaviour have been tested:
$ systemctl hibernate
$ systemctl hybrid-sleep
$ systemctl suspend-then-hibernate

These commands require an authorisation policy that permits the operation, and they will interrupt services and your own shell session. Keep this for last: finish the read-only checks and configuration below first. Recovery is normally just the next resume; if a machine will not resume, use its local power and firmware recovery procedure rather than repeatedly retrying over an untested remote connection.

4. Inspect the current sleep configuration

Systemd reads the main sleep configuration and drop-ins from the system configuration directories. Local administrator files belong under /etc/systemd/sleep.conf.d/. Read what already exists before adding an override:

$ sed -n '1,220p' /etc/systemd/sleep.conf 2>/dev/null
$ find /usr/lib/systemd/sleep.conf.d /usr/local/lib/systemd/sleep.conf.d \
    /etc/systemd/sleep.conf.d -maxdepth 1 -type f -name '*.conf' \
    -printf '%p\n' 2>/dev/null | sort

Drop-ins outrank the main file. Files are sorted lexicographically, and for a single-value option the last setting wins, which is why a name like 60-laptop.conf makes the ordering visible. A package may install a later file too, so check the full list again after any change.

5. Add one reversible policy

For a laptop that supports it, this example pins the kernel's freeze suspend state explicitly. Use whatever value you saw in step 2 if freeze is not there:

$ sudo install -d -m 0755 /etc/systemd/sleep.conf.d
$ sudoedit /etc/systemd/sleep.conf.d/60-laptop.conf

Put these lines in the editor:

[Sleep]
SuspendState=freeze

SuspendState= accepts one or more whitespace-separated values and tries them in order until one can be written. SuspendState=freeze mem, for example, gives you a fallback, but only ever list values you saw in /sys/power/state. The equivalent hibernation setting is HibernateMode=, whose values must come from /sys/power/disk instead.

To disable a mode systemd advertises, use the matching Allow... setting. This example prevents hibernation, and with it suspend-then-hibernate and hybrid sleep unless those specific modes are re-enabled explicitly:

[Sleep]
AllowHibernation=no

Do not add that restriction casually: it changes what desktop tools and policy checks may offer. To undo either example, remove the setting or the whole drop-in, then confirm it is gone:

$ sudo rm /etc/systemd/sleep.conf.d/60-laptop.conf
$ test ! -e /etc/systemd/sleep.conf.d/60-laptop.conf && echo 'override removed'
override removed

Warning

That removal is destructive to the local file. If it holds other settings too, edit it and remove only the relevant line instead of deleting the whole thing.

6. Configure suspend-then-hibernate deliberately

HibernateDelaySec= only applies to suspend-then-hibernate. On a machine without a battery, the installed documentation says the default delay is two hours when this setting is absent. On battery power, systemd can use low-battery alarms or periodic checks instead, and setting a delay changes how it schedules those checks. A short test value is easier to reason about:

[Sleep]
HibernateDelaySec=45min

Combine it with a valid suspend state only after checking the files from step 2. SuspendEstimationSec= is a fallback interval for battery estimation, available since systemd 253 and so present in this installation. It is not a general sleep timeout, do not treat it as one.

Keep the delay long enough to resume the machine normally while testing. A suspend-then-hibernate test that runs overnight is a real power-state transition, not a configuration-only exercise.

7. Understand system-sleep hooks before adding one

Before and after a sleep action, systemd runs executable files in /usr/lib/systemd/system-sleep/. Each receives pre or post as its first argument and the action name as its second. SYSTEMD_SLEEP_ACTION carries the action too, including a special failed-hibernation value for suspend-then-hibernate.

These hooks run in parallel and systemd waits for all of them to finish. The manpage itself calls them local-use hacks: applications that need to react to suspend and resume should use the inhibitor interface instead. Before trusting a hook, list it and check its permissions without running it:

$ find /usr/lib/systemd/system-sleep -maxdepth 1 -type f -executable \
    -printf '%f\n' | sort

Do not put a slow backup, a network dependency or an irreversible command in there. A failing or hanging hook delays the sleep transition and makes diagnosis harder. Remove a hook only once you know which package owns it; package-managed files should be changed through package configuration, not deleted by hand.

Done means

  • Version and mapping checked: you identified the installed systemd version and the unit-to-action mapping.
  • Kernel states read: you read /sys/power/state and /sys/power/disk instead of guessing values.
  • Mode chosen deliberately: you picked a sleep action with its power-loss and resume trade-off understood.
  • Change is a named drop-in: any local change lives in /etc/systemd/sleep.conf.d/*.conf.
  • Removal path known: you know how to remove the drop-in, and have not tested sleep over an unverified remote path.
  • Test planned last: a planned systemctl sleep and resume test is the final step, done with local recovery available.