On Thu, Dec 29, 2016 at 3:39 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-12-29 13:02, Andrei Borzenkov wrote:
On Thu, Dec 29, 2016 at 2:34 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Hi,
I see scripts in "/usr/lib/systemd/system-sleep/". What would be the right place to add my own scripts?
It depends on what this script does.
For example, send pending nntp messages before going into hibernation.
system-sleep is too late for this.
This is because there is a cron job that does it, but I might write a message and go into hibernation immediately, before the cron job runs. If I awake the machine a day later, the upstream server rejects the post because it is too old.
For example, abort hibernation if vmware is running, or if there is an active nfs share. The reason is because I have seen crashes in both circumstances.
Another thing I did was stop and start ntp. On the laptop, instead, I trigger ntptimeset on restore, I do not use the daemon.
These are things I did with "pm"
I hoped for /etc/systemd/system-sleep/
A pointer to reading about them?
"man systemd-sleep" and "man bootup" would be a good start
I want to know the available parameters that the scripts in "/usr/lib/systemd/system-sleep/" can use. I know, by looking at the current scripts, that $2 can be "suspend", "hibernate", or "hybrid-sleep", that $1 can be "pre" or "post"... but the man page does not explain.
It does in TW (and current upstream).
And I need to know how to abort hibernation. Previously a flag file did the trick:
{backup}/usr/lib/pm-utils/pm-functions:
INHIBIT="${STORAGEDIR}/inhibit"
I am afraid there is no similar or even simple way. First, it is impossible to directly cancel suspend request. You can delay it, block it, or /may be/ (not tested) insert service that is required by sleep.target and does some checks and fails startup. Then attempt to start suspend will fail due to dependencies. To execute actions on suspend you can add services or use inhibitors. Services will run unconditionally; inhibitors will need to listen for signals, execute actions, release inhibitors and reinstate them after resume. That probably involves writing (yet another) daemon. In both cases the problem is ordering between different actions. I.e. NetworkManager will also listen for signals and stop interfaces on suspend. This happens *before* actually actovating systemd units. So you have race here - if you need network to perform some actions during suspend, it may be unavailable when you get to execute these actions. Basically systemd position is - each service must be intelligent enough to handle whatever happens around suspend/resume, so manager need not be very clever here. If all you concerns are about network related stuff, you may consider hooking into NetworkManager (see dispatcher). Not sure if something like this exists for wicked. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org