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?










share|improve this question

















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.




















    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?










    share|improve this question

















    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.


















      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?










      share|improve this question















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      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.
























          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'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.






          share|improve this answer

















          • 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











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          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

























          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'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.






          share|improve this answer

















          • 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















          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'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.






          share|improve this answer

















          • 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













          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'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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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














          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Accessing regular linux commands in Huawei's Dopra Linux

          Can't connect RFCOMM socket: Host is down

          Kernel panic - not syncing: Fatal Exception in Interrupt