pm-suspend vs systemctl suspend?
up vote
1
down vote
favorite
For Linux distributions using systemd, is there a practical difference between these two commands?
systemctl suspend
pm-suspend
Which should I use or prefer?
systemd suspend systemctl pm-utils
This question has an open bounty worth +50
reputation from Evan Carroll ending in 5 days.
One or more of the answers is exemplary and worthy of an additional bounty.
add a comment |
up vote
1
down vote
favorite
For Linux distributions using systemd, is there a practical difference between these two commands?
systemctl suspend
pm-suspend
Which should I use or prefer?
systemd suspend systemctl pm-utils
This question has an open bounty worth +50
reputation from Evan Carroll ending in 5 days.
One or more of the answers is exemplary and worthy of an additional bounty.
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
For Linux distributions using systemd, is there a practical difference between these two commands?
systemctl suspend
pm-suspend
Which should I use or prefer?
systemd suspend systemctl pm-utils
For Linux distributions using systemd, is there a practical difference between these two commands?
systemctl suspend
pm-suspend
Which should I use or prefer?
systemd suspend systemctl pm-utils
systemd suspend systemctl pm-utils
edited yesterday
Filipe Brandenburger
6,6701732
6,6701732
asked Nov 28 at 0:16
Evan Carroll
4,98994176
4,98994176
This question has an open bounty worth +50
reputation from Evan Carroll ending in 5 days.
One or more of the answers is exemplary and worthy of an additional bounty.
This question has an open bounty worth +50
reputation from Evan Carroll ending in 5 days.
One or more of the answers is exemplary and worthy of an additional bounty.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
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'ssystemd-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 asleep.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
yesterday
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
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'ssystemd-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 asleep.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
yesterday
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
add a comment |
up vote
4
down vote
accepted
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'ssystemd-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 asleep.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
yesterday
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
add a comment |
up vote
4
down vote
accepted
up vote
4
down vote
accepted
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'ssystemd-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 asleep.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.
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'ssystemd-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 asleep.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.
answered yesterday
Filipe Brandenburger
6,6701732
6,6701732
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
yesterday
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
add a comment |
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
yesterday
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
1
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
yesterday
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
yesterday
1
1
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
+1. Did systemctl play a role in the problems that I encountered here unix.stackexchange.com/questions/435168/…?
– Tim
yesterday
1
1
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
Wow thanks for the bounty @EvanCarroll!!!
– Filipe Brandenburger
yesterday
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484550%2fpm-suspend-vs-systemctl-suspend%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown