The purpose of this page is to provide general overview of power management in Arch Linux. As Arch Linux uses [[systemd]] as system manager, this article focuses on it.

The purpose of this page is to provide general overview of power management in Arch Linux. As Arch Linux uses [[systemd]] as system manager, this article focuses on it.

Line 40:

Line 43:

{{Note|

{{Note|

−

* Run {{ic|systemctl restart systemd-logind}} for your changes to take effect.

+

* [[systemd#Using units|Restart]] the {{ic|systemd-logind}} daemon for your changes to take effect.

* ''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.

* ''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.

}}

}}

Line 54:

Line 57:

{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]] or [[TuxOnIce]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}

{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]] or [[TuxOnIce]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}

−

{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Pm-utils#Hibernation (suspend2disk)]] and possibly at [[Pm-utils#Mkinitcpio Resume Hook]] (''pm-utils'' does ''not'' need to be installed).

+

{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Suspend and Hibernate#Hibernation]].

=== Sleep hooks ===

=== Sleep hooks ===

Line 62:

Line 65:

==== Suspend/resume service files ====

==== Suspend/resume service files ====

−

Service files can be hooked into ''suspend.target'', ''hibernate.target'' and ''sleep.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. To activate the user service files run {{ic|systemctl enable suspend@''user'' && systemctl enable resume@''user''}}. Examples:

+

Service files can be hooked into ''suspend.target'', ''hibernate.target'' and ''sleep.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. [[systemd#Using units|Enable]] the {{ic|suspend@''user''}} and {{ic|resume@''user''}} services to have them started at boot. Examples:

systemd cannot handle AC and Battery ACPI events, so if you use Laptop Mode Tools or other similar tools acpid is still required.

In the current version of systemd, the Handle* options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.

Warning: Currently, the power managers in the newest versions of KDE and GNOME are the only ones that issue the necessary "inhibited" commands. Until the others do, you will need to set the Handle options to ignore if you want your ACPI events to be handled by Xfce, acpid or other programs.

Suspend and hibernate

systemd provides commands for suspend to RAM, hibernate and a hybrid suspend using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.

Note: systemd can also use other suspend backends (such as Uswsusp or TuxOnIce), in addition to the default kernel backend, in order to put the computer to sleep or hibernate. See Uswsusp#With systemd for an example.

systemctl suspend should work out of the box, for systemctl hibernate to work on your system you need to follow the instructions at Suspend and Hibernate#Hibernation.

Sleep hooks

systemd does not use pm-utils to put the machine to sleep when using systemctl suspend, systemctl hibernate or systemctl hybrid-sleep; pm-utils hooks, including any custom hooks, will not be run. However, systemd provides two similar mechanisms to run custom scripts on these events.

Suspend/resume service files

Service files can be hooked into suspend.target, hibernate.target and sleep.target to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. Enable the suspend@user and resume@user services to have them started at boot. Examples:

A couple of handy hints about these service files (more in man systemd.service):

If Type=OneShot then you can use multiple ExecStart= lines. Otherwise only one ExecStart line is allowed. You can add more commands with either ExecStartPre or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are required).

A command prefixed with - will cause a non-zero exit status to be ignored and treated as a successful command.

The best place to find errors when troubleshooting these service files is of course with journalctl.

Combined Suspend/resume service file

With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).

RemainAfterExit=yes: After started, the service is considered active until it is explicitly stopped.

StopWhenUnneeded=yes: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after sleep.target is stopped.

Because sleep.target is pulled in by suspend.target, hibernate.target and hybrid-sleep.target and sleep.target itself is a StopWhenUnneeded service, the hook is guaranteed to start/stop properly for different tasks.

Hooks in /usr/lib/systemd/system-sleep

systemd runs all executables in /usr/lib/systemd/system-sleep/, passing two arguments to each of them:

Argument 1: either pre or post, depending on whether the machine is going to sleep or waking up

Argument 2: suspend, hibernate or hybrid-sleep, depending on which is being invoked

In contrast to pm-utils, systemd will run these scripts concurrently and not one after another.

The output of any custom script will be logged by systemd-suspend.service, systemd-hibernate.service or systemd-hybrid-sleep.service. You can see its output in systemd's journal:

# journalctl -b -u systemd-suspend

Note: You can also use sleep.target, suspend.target, hibernate.target or hybrid-sleep.target to hook units into the sleep state logic instead of using custom scripts.