7

For Linux distributions using systemd, is there a practical difference between these two commands?

  • systemctl suspend
  • pm-suspend

Which should I use or prefer?

9

In short, you should generally prefer the suspend mode integrated by your distro. For distros that ship systemd, that's typically systemctl suspend.

For instance, the Arch Linux wiki says:

systemd provides native commands for suspend, hibernate and a hybrid suspend, see "Power management with systemd" for details. This is the default interface used in Arch Linux.

And for Debian Jessie:

With systemd, pm-utils and its hooks are not used any more, instead there's systemd-suspend.


The reason why you want to stick with what your distro uses is that their packages which care about suspend/resume will ship hook scripts that integrate with either pm-utils (/usr/lib/pm-utils/sleep.d) or systemd (/usr/lib/systemd/system-sleep/), so you should use the same interface in order to have all the proper hooks run as expected.

Furthermore, distros will typically hook the proper suspend/hibernate method into ACPI for hardware events, desktop environments (for shutdown buttons that allow for suspend/hibernate), and with screen savers/locks, etc.


Both pm-suspend and systemd-suspend use typically the same interfaces to actually put the computer to sleep.

Both default to using the kernel's suspend driver (by writing to /sys/power/state) and both support external suspend drivers (such as uswsusp, see here for details on how to hook it into systemd.)

They both support configuration files and hook scripts that are called in the process of suspending or resuming, the main difference being the location of the files (the API of the hooks is very similar):

  • pm-utils reads its configuration from files in /etc/pm/config.d and executes hooks from both /etc/pm/sleep.d and /usr/lib/pm-utils/sleep.d directories.
  • systemd-suspend reads its configuration from the /etc/systemd/sleep.conf file (or files in a sleep.conf.d directory) and executes hooks from /usr/lib/systemd/system-sleep/.

So, from that point of view, both look very similar...

But systemd goes further into its support for suspend/hibernate/resume, since:

  • You can hook systemd units into the suspend/resume process, for instance running them before suspending or after resuming. (You can find great recipes here.)
  • systemd supports a D-Bus interface, so one can trigger suspend by using a D-Bus call rather than running a command (though running systemctl suspend is still of course an option.) Triggering suspend through D-Bus rather than by running a command is typically useful from a desktop environment.
  • systemd has an advanced interface for notifying and having userspace applications delaying suspend while they're completing operations, the inhibitor interface, which is more flexible and convenient than the hook scripts. (In fact, systemd recommends using this interface rather than hook scripts whenever possible.)

So even though both pm-utils and systemd-suspend achieve the actual suspend of the system in about the same ways, the integration with the other components of the system makes it so that it matters which one is called... And on distributions shipping systemd, then systemctl suspend is typically the right one to call.

  • 1
    This is a really great answer that covers all the bases. Thanks for the background! I don't see Xubuntu using pm-suspend, so perhaps in the pre-systemd days I installed it and never removed it, and I was the only one using it. Debian does a real shit job of telling you when there is a newer way to do something. – Evan Carroll Nov 30 '18 at 2:40
  • 1
    +1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…? – Tim Nov 30 '18 at 2:52
  • 1
    Wow thanks for the bounty @EvanCarroll!!! – filbranden Nov 30 '18 at 4:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.