systemd-suspend.servicesystemdsystemd-suspend.service8systemd-suspend.servicesystemd-hibernate.servicesystemd-hybrid-sleep.servicesystemd-suspend-then-hibernate.servicesystemd-sleepSystem sleep state logicsystemd-suspend.servicesystemd-hibernate.servicesystemd-hybrid-sleep.servicesystemd-suspend-then-hibernate.service/usr/lib/systemd/system-sleepDescriptionsystemd-suspend.service is a system
service that is pulled in by suspend.target
and is responsible for the actual system suspend. Similarly,
systemd-hibernate.service is pulled in by
hibernate.target to execute the actual
hibernation. Finally,
systemd-hybrid-sleep.service is pulled in by
hybrid-sleep.target to execute hybrid
hibernation with system suspend and pulled in by
suspend-then-hibernate.target to execute system suspend
with a timeout that will activate hibernate later.Immediately before entering system suspend and/or
hibernation systemd-suspend.service (and the
other mentioned units, respectively) will run all executables in
/usr/lib/systemd/system-sleep/ and pass two
arguments to them. The first argument will be
pre, the second either
suspend, hibernate,
hybrid-sleep, or suspend-then-hibernate
depending on the chosen action. An environment variable called SYSTEMD_SLEEP_ACTION
will be set and contain the sleep action that is processing. This is primarily helpful for
suspend-then-hibernate where the value of the variable will be suspend, hibernate,
or suspend-after-failed-hibernate in cases where hibernation has failed.
Immediately after leaving system suspend and/or hibernation the
same executables are run, but the first argument is now
post. All executables in this directory are
executed in parallel, and execution of the action is not continued
until all executables have finished. Note that user.slice will
be frozen while the executables are running, so they should not attempt to
communicate with any user services expecting a reply.Note that scripts or binaries dropped in
/usr/lib/systemd/system-sleep/ are intended
for local use only and should be considered hacks. If applications
want to react to system suspend/hibernation and resume, they should rather use the
Inhibitor Locks.Note that systemd-suspend.service,
systemd-hibernate.service, systemd-hybrid-sleep.service, and
systemd-suspend-then-hibernate.service should never be executed directly. Instead,
trigger system sleep with a command such as systemctl suspend or systemctl
hibernate.Internally, this service will echo a string like
mem into /sys/power/state,
to trigger the actual system suspend. What exactly is written
where can be configured in the [Sleep] section
of /etc/systemd/sleep.conf or a
sleep.conf.d file. See
systemd-sleep.conf5.
Note that by default these services freeze user.slice while they run. This prevents
the execution of any process in any of the user sessions while the system is entering into and resuming from
sleep. Thus, this prevents the hooks in /usr/lib/systemd/system-sleep/, or any other process
for that matter, from communicating with any user session process during sleep.Optionssystemd-sleep understands the
following commands:Suspend, hibernate, suspend then hibernate, or put the
system to hybrid sleep.See Alsosystemd-sleep.conf5systemd1systemctl1systemd.special7systemd-halt.service8