[opensuse] systemd hibernate dirs
Hi, I see scripts in "/usr/lib/systemd/system-sleep/". What would be the right place to add my own scripts? A pointer to reading about them? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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.
A pointer to reading about them?
"man systemd-sleep" and "man bootup" would be a good start -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. 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. 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" -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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
On 2016-12-29 14:44, Andrei Borzenkov wrote:
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.
Oh.
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).
Ok, I will try to boot my TW image and check.
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.
Then I see no solution but write my own hibernation script, which does whichever needs to be done, and then call "systemctl hibernate" or not. And remember to use it always. What a pain. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Hi Carlos, [...]
For example, send pending nntp messages before going into hibernation.
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.
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished. And: It works only with NM versions > 1.2.2. At the moment in Leap 42.2 I use 1.4.4 from the Tumbleweed repo. You might be lucky, if the actions to be performed don't last too long. ------------------------< snip snip snip >----------------------------- #!/bin/bash INTERFACE="$1" ACTION="$2" case "$ACTION" in pre-down|vpn-pre-down) # ... ;; esac ------------------------< snip snip snip >----------------------------- If anyone has a better workflow for things like that, I would be really grateful.
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.
To my knowledge there is no way to abort an initiated hibernation process from any of the given scripts.
Another thing I did was stop and start ntp. On the laptop, instead, I trigger ntptimeset on restore, I do not use the daemon.
This can also be done via NM's dispatcher scripts. [...] Another thing you could try is to write your own dbus scripts listening to the appropriate events. There you can use inhibitors to slow down the hibernations process for a maximum of 5 seconds. If you are interested, I could send you my dbus scripts for logind, which handles things like sleep and resume, and for NM, which handles network interface ups and downs. Based on perl and the Net::DBus module, the scripts are far from being perfect, but for my notebook and my desktop they do almost every job, I wanted to implement.
Cheers / Saludos,
Carlos E. R.
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
not a direct solution, but to add to options: https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-07 11:29, nicholas wrote:
not a direct solution, but to add to options: https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
Ah... Interesting. --mode= Takes either "block" or "delay" and describes how the lock is applied. If "block" is used (the default), the lock prohibits any of the requested operations without time limit, and only privileged users may override it. If "delay" is used, the lock can only delay the requested operations for a limited time. If the time elapses, the lock is ignored and the operation executed. The time limit may be specified in logind.conf(5). Note that "delay" is only available for "sleep" and "shutdown". But it is for executing a program. Example # systemd-inhibit wodim foobar.iso This burns the ISO image foobar.iso on a CD using wodim(1), and inhibits system sleeping, shutdown and idle while doing so. So not for an automatic lock if a condition is met. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
07.01.2017 13:04, Michael Hirmke пишет:
Hi Carlos,
[...]
For example, send pending nntp messages before going into hibernation.
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.
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished.
According to documentation pre-down The interface will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and NetworkManager will wait for script execution to complete before disconnecting the interface from its network. So where is your script located? If NM does not wait for it to finish it sounds like a bug. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Andrei, [...]
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished.
According to documentation
pre-down The interface will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and NetworkManager will wait for script execution to complete before disconnecting the interface from its network.
So where is your script located? If NM does not wait for it to finish it sounds like a bug.
The scripts are located in the correct sub directories. With NM < 1.2.2.x they were not executed at all. With the newer versions they are executed, but if they take too long, NM already starts shutting down the interface. If I remember correctly, this was not seen as a bug, but as intended behaviour. Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/17 11:11, Michael Hirmke wrote:
The scripts are located in the correct sub directories. With NM < 1.2.2.x they were not executed at all. With the newer versions they are executed, but if they take too long, NM already starts shutting down the interface. If I remember correctly, this was not seen as a bug, but as intended behaviour.
It would be nice if the script could tell NM how long is "too long". It is intended because the whole point of systemd is that it will force the system down regardless if a shutdown script hangs. Unfortunately, there's a whole bunch of corner cases which haven't yet been fixed and networking seems to be the prime example. Eg mine, where I want my network mounts to run as part of system startup/shutdown, but it's a laptop and the network relies on login/logout. So the system hangs either on boot or on shutdown :-( Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Wols, [...]
Unfortunately, there's a whole bunch of corner cases which haven't yet been fixed and networking seems to be the prime example. Eg mine, where I want my network mounts to run as part of system startup/shutdown, but it's a laptop and the network relies on login/logout. So the system hangs either on boot or on shutdown :-(
this works perfectly for me, because mount/umount return very quick. There even is a script distributed in /etc/NetworkManager/dispatcher.d called "nfs" to handle nfs mounts in case of stopping/starting a network interface.
Cheers, Wol
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/17 12:37, Michael Hirmke wrote:
Hi Wols,
[...]
Unfortunately, there's a whole bunch of corner cases which haven't yet been fixed and networking seems to be the prime example. Eg mine, where I want my network mounts to run as part of system startup/shutdown, but it's a laptop and the network relies on login/logout. So the system hangs either on boot or on shutdown :-(
this works perfectly for me, because mount/umount return very quick. There even is a script distributed in /etc/NetworkManager/dispatcher.d called "nfs" to handle nfs mounts in case of stopping/starting a network interface.
Can you explain how you do this, then? I've put the mounts in fstab (which is probably a mistake), but trying to find info is an exercise in frustration. I've had hints from this list already, which I haven't tried to implement, but it would be wonderful to have a cheat-sheet to follow. (Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
07.01.2017 18:26, Wols Lists пишет:
(Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
"Doctor, it hurts when I stab myself in the eye". Of course you cannot store secrets required to bring up network on a filesystem that is not available before network is up. I am not sure what miracles you expect here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/17 15:36, Andrei Borzenkov wrote:
07.01.2017 18:26, Wols Lists пишет:
(Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
"Doctor, it hurts when I stab myself in the eye".
Of course you cannot store secrets required to bring up network on a filesystem that is not available before network is up. I am not sure what miracles you expect here.
I would like to be able to store them on a local filesystem, perhaps? And have the system bring the network up as part of the boot procedure, which is where I expect it happen? Have you heard the saying "a little knowledge is a dangerous thing"? My knowledge of networking is pretty decent, but of Network Manager and friends it's a case of "I let the wizard handle it". And said wizard has plonked me into this catch-22. How do I fix my system so that it does NOT default to a broken configuration? And yet correctly mounts the filesystems I want available? Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
07.01.2017 18:47, Wols Lists пишет:
On 07/01/17 15:36, Andrei Borzenkov wrote:
07.01.2017 18:26, Wols Lists пишет:
(Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
"Doctor, it hurts when I stab myself in the eye".
Of course you cannot store secrets required to bring up network on a filesystem that is not available before network is up. I am not sure what miracles you expect here.
I would like to be able to store them on a local filesystem, perhaps? And have the system bring the network up as part of the boot procedure, which is where I expect it happen?
That is what NM does if you use system connection (some frontends call it "available to all users"). Necessary credentials are stored in root filesystem.
Have you heard the saying "a little knowledge is a dangerous thing"? My knowledge of networking is pretty decent, but of Network Manager and friends it's a case of "I let the wizard handle it". And said wizard has plonked me into this catch-22.
It helps if you tell more details; there are at least three different frontends to NM (original nm-connection-editor, GNOME shell frontend, KDE frontend). I do not know what each one defaults to. I started nm-connection-editor and "connection available to all users" was enabled when creating new connection.
How do I fix my system so that it does NOT default to a broken configuration? And yet correctly mounts the filesystems I want available?
Assuming you are using NM and connection that requires credentials (like WiFi), you edit connection and look for "System connection" or "available to all users" or similar checkbox. Otherwise please tell more details about your environment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/17 17:15, Andrei Borzenkov wrote:
07.01.2017 18:47, Wols Lists пишет:
On 07/01/17 15:36, Andrei Borzenkov wrote:
07.01.2017 18:26, Wols Lists пишет:
(Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
"Doctor, it hurts when I stab myself in the eye".
Of course you cannot store secrets required to bring up network on a filesystem that is not available before network is up. I am not sure what miracles you expect here.
I would like to be able to store them on a local filesystem, perhaps? And have the system bring the network up as part of the boot procedure, which is where I expect it happen?
That is what NM does if you use system connection (some frontends call it "available to all users"). Necessary credentials are stored in root filesystem.
Have you heard the saying "a little knowledge is a dangerous thing"? My knowledge of networking is pretty decent, but of Network Manager and friends it's a case of "I let the wizard handle it". And said wizard has plonked me into this catch-22.
It helps if you tell more details; there are at least three different frontends to NM (original nm-connection-editor, GNOME shell frontend, KDE frontend). I do not know what each one defaults to. I started nm-connection-editor and "connection available to all users" was enabled when creating new connection.
I'm guessing it's KDE front end. I've installed bog-standard 42.2 (actually, upgraded from 42.1) and I clicked on the network icon at the bottom right of my desktop to configure it.
How do I fix my system so that it does NOT default to a broken configuration? And yet correctly mounts the filesystems I want available?
Assuming you are using NM and connection that requires credentials (like WiFi), you edit connection and look for "System connection" or "available to all users" or similar checkbox. Otherwise please tell more details about your environment.
Okay, I will look at that next time I fire up my laptop (I'm on my gentoo desktop at the moment). Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Wols, [...]
this works perfectly for me, because mount/umount return very quick. There even is a script distributed in /etc/NetworkManager/dispatcher.d called "nfs" to handle nfs mounts in case of stopping/starting a network interface.
Can you explain how you do this, then? I've put the mounts in fstab (which is probably a mistake), but trying to find info is an exercise in frustration. I've had hints from this list already, which I haven't tried to implement, but it would be wonderful to have a cheat-sheet to follow.
a better way to it is to create systemd mount units, but it can be done with fstab entries, too. You have a look at the nfs dispatcher script I mentioned. Everything you need is in it. The fstab entries may not have the auto option!
(Oh, and while it's not important, could your method cope with an nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
I have my home on nfs, too. It is mounted, as soon as the according network interface comes up, and umounted before it goes down. I don't use secrets or things like that, but the old nfs v3 logics with same uids on all machines - this also works with nfs v4.1 here.
Cheers, Wol
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/17 17:00, Michael Hirmke wrote:
(Oh, and while it's not important, could your method cope with an
nfs-mount home? Perfect little catch-22 - the network won't come up until the user is logged in, but there's no home directory until the user is logged in ... :-)
I have my home on nfs, too. It is mounted, as soon as the according network interface comes up, and umounted before it goes down. I don't use secrets or things like that, but the old nfs v3 logics with same uids on all machines - this also works with nfs v4.1 here.
My problem is it's a laptop ... the network interface comes up AFTER the user has logged in - hence the catch-22 :-( Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-07 19:44, Wols Lists wrote:
My problem is it's a laptop ... the network interface comes up AFTER the user has logged in - hence the catch-22 :-(
Not if you make it a system connection or available for other users. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Hi Wols, [...]
I have my home on nfs, too. It is mounted, as soon as the according network interface comes up, and umounted before it goes down. I don't use secrets or things like that, but the old nfs v3 logics with same uids on all machines - this also works with nfs v4.1 here.
My problem is it's a laptop ... the network interface comes up AFTER the user has logged in - hence the catch-22 :-(
then you have to follow Carlos' advice.
Cheers, Wol
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-07 12:11, Michael Hirmke wrote:
The scripts are located in the correct sub directories. With NM < 1.2.2.x they were not executed at all. With the newer versions they are executed, but if they take too long, NM already starts shutting down the interface. If I remember correctly, this was not seen as a bug, but as intended behaviour.
I have NM scripts that run on connection up, but after a delay NM kills it and children. I had to capture the kill signal to avoid it, if I remember correctly. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
07.01.2017 14:11, Michael Hirmke пишет:
Hi Andrei,
[...]
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished.
According to documentation
pre-down The interface will be deactivated but has not yet been disconnected from the network. Scripts acting on this event must be placed or symlinked into the /etc/NetworkManager/dispatcher.d/pre-down.d directory, and NetworkManager will wait for script execution to complete before disconnecting the interface from its network.
So where is your script located? If NM does not wait for it to finish it sounds like a bug.
The scripts are located in the correct sub directories. With NM < 1.2.2.x they were not executed at all. With the newer versions they are executed, but if they take too long, NM already starts shutting down the interface. If I remember correctly, this was not seen as a bug, but as intended behaviour.
Documentation states that NM waits for completion. Do you have pointers to discussion? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Andrei, [...]
The scripts are located in the correct sub directories. With NM < 1.2.2.x they were not executed at all. With the newer versions they are executed, but if they take too long, NM already starts shutting down the interface. If I remember correctly, this was not seen as a bug, but as intended behaviour.
Documentation states that NM waits for completion. Do you have pointers to discussion?
no, sorry. Thats why I wrote "if I remember correctly". But the last time I tested it completely, was with NM 1.2.2. I implemented a few workarounds then. I should test it with 1.4.4 without the workarounds to make sure, the situation is the same. Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-07 11:04, Michael Hirmke wrote:
Hi Carlos,
[...]
For example, send pending nntp messages before going into hibernation.
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.
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished. And: It works only with NM versions > 1.2.2. At the moment in Leap 42.2 I use 1.4.4 from the Tumbleweed repo. You might be lucky, if the actions to be performed don't last too long.
It appears that the best option for me is to create a wrapper script that does the needed tasks, and when done, calls systemd to perform the hibernation, or aborts with a message if not possible. Some things could go to the systemd directory. I'm used to always call hibernation from the command "pm-hibernation", and never from the menu, so calling a script instead is no big issue. Why don't I use the menu? Because it does not work in xfce. Two issues: in one mode, it first blanks the screen, then it asks the root password to perform the action, which of course I never see and it never hibernates. The other failure mode is that it refuses to hibernate if thinks there is a root console open. There are old bugzillas for these. So I ended by using pm-hibernate as root or via sudo. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-01-07 a las 14:58 +0100, Carlos E. R. escribió:
On 2017-01-07 11:04, Michael Hirmke wrote:
Hi Carlos,
[...]
For example, send pending nntp messages before going into hibernation.
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.
I tried to put things like that into the NetworkManager dispatcher scripts in /etc/NetworkManager/dispatcher.d, but even here sometimes it is too late, because NM stops the interfaces faster than my dispatcher scripts finished. And: It works only with NM versions > 1.2.2. At the moment in Leap 42.2 I use 1.4.4 from the Tumbleweed repo. You might be lucky, if the actions to be performed don't last too long.
It appears that the best option for me is to create a wrapper script that does the needed tasks, and when done, calls systemd to perform the hibernation, or aborts with a message if not possible. Some things could go to the systemd directory.
It appears that it is possible to abort hibernation. See this: cer@minas-tirith:~> systemctl hibernate User root is logged in on sshd. Please retry operation after closing inhibitors and logging out other users. Alternatively, ignore inhibitors and users with 'systemctl hibernate -i'. cer@minas-tirith:~> So, the question now is to find out what those "inhibitors" are. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAliZVHkACgkQja8UbcUWM1zWbAD/Wp3z+MqR7MlVtdQaaEYxnWAo wqWGxxcXl2bfO6PdbyUA/3Nu5mVtE9vEFhPJApFmzgPxfacrnL3dLMni5dMmbSLT =3WMt -----END PGP SIGNATURE-----
On 2017-02-09 18:56, Andrei Borzenkov wrote:
07.02.2017 08:00, Carlos E. R. пишет:
So, the question now is to find out what those "inhibitors" are.
man systemd-inhibit
Thanks. (read). I have to think it over. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
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.
A pointer to reading about them?
"man systemd-sleep" and "man bootup" would be a good start The manual page systemd-sleep.conf(5) says
NAME systemd-sleep.conf, sleep.conf.d - Suspend and hibernation configuration file SYNOPSIS /etc/systemd/sleep.conf /etc/systemd/sleep.conf.d/*.conf /run/systemd/sleep.conf.d/*.conf /usr/lib/systemd/sleep.conf.d/*.conf Unfortunately none of the directories exist on Tumbleweed. May be /etc/systemd/sleep.conf.d/*.conf works, if the directory is created. It looks like a documentation issue. My own scripts are in /usr/lib/systemd/system-sleep, which isn't an ideal place for user defined scripts. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 6 January 2017 16:21:22 CET Bjoern Voigt wrote:
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.
A pointer to reading about them?
"man systemd-sleep" and "man bootup" would be a good start
The manual page systemd-sleep.conf(5) says
NAME systemd-sleep.conf, sleep.conf.d - Suspend and hibernation configuration file
SYNOPSIS /etc/systemd/sleep.conf
/etc/systemd/sleep.conf.d/*.conf
/run/systemd/sleep.conf.d/*.conf
/usr/lib/systemd/sleep.conf.d/*.conf
Unfortunately none of the directories exist on Tumbleweed. May be /etc/systemd/sleep.conf.d/*.conf works, if the directory is created. It looks like a documentation issue.
My own scripts are in /usr/lib/systemd/system-sleep, which isn't an ideal place for user defined scripts.
Greetings, Björn to my knowledge these are USER DEFINED drop-in directories https://www.freedesktop.org/software/systemd/man/systemd.unit.html
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-06 16:21, Bjoern Voigt wrote:
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.
A pointer to reading about them?
"man systemd-sleep" and "man bootup" would be a good start The manual page systemd-sleep.conf(5) says
NAME systemd-sleep.conf, sleep.conf.d - Suspend and hibernation configuration file
SYNOPSIS /etc/systemd/sleep.conf
/etc/systemd/sleep.conf.d/*.conf
/run/systemd/sleep.conf.d/*.conf
/usr/lib/systemd/sleep.conf.d/*.conf
Unfortunately none of the directories exist on Tumbleweed.
Nor on Leap. Not clear what one can do with those config files, though... :-? It seems very little.
May be /etc/systemd/sleep.conf.d/*.conf works, if the directory is created. It looks like a documentation issue.
My own scripts are in /usr/lib/systemd/system-sleep, which isn't an ideal place for user defined scripts.
My thought exactly. I will create my own wrapper script, that does needed checks in the appropriate sequence, then tell systemd to hibernate, or abort if not possible. And use the system-sleep scripts to undo on return. (time permitting...) I was point to this link: https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks it seems good. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (6)
-
Andrei Borzenkov -
Bjoern Voigt -
Carlos E. R. -
mh＠mike.franken.de -
nicholas -
Wols Lists