custom pre/post suspend scripts shoud not live in /lib

[Bas Zoetekouw]

The systemd-sleep manpage mentions the following:

       Finally, systemd-hybrid-sleep.service is pulled in by hybrid-sleep.target to execute hybrid hibernation with system suspend.

       Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /lib/systemd/system-sleep/ and pass two arguments to them. The first argument
       will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. 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 scripts or binaries dropped in /lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces
       available.

It is unfortunate that such "hacks" are generally still required to get a laptop to suspend/hibernate and resume correctly.

However, I don't think /lib is the proper place for such scripts, especially for those that are added by local administrators. As far as I know, /lib is handled by dpkg and it should never be required to add stuff there manually. Note that the FHS is also quite specific in this regard: "The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin.". This doesn't seem to include custom scripts as used here.

 A better place would probably be /etc/systemd (similar to the obsolete /etc/pm/sleep.d). At the very least, /lib/systemd/systemd-sleep should contain a script that calls user-provided scripts from a more appropriate location.

[Steve Dodd (anarchetic)]

https://github.com/systemd/systemd/issues/4927 is probably the relevant upstream bug