[systemd-devel] How to prevent sleep during running oneshot units
hurikhan77 at gmail.com
Tue Feb 11 17:12:15 PST 2014
Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> schrieb:
>> There may be a bug here, because almost every time when that happened it
>> looks like systemd has suspended my network connection but didn't bring
>> it back online after the system refused to go to sleep. I need to restart
>> NetworkManager then or reboot (I prefer reboot to alleviate any other
>> side effects that may have had).
> This sounds like an NM problem. Afaik, doesn't do anything special with
> network interfaces when suspending.
Hmm okay... I will try to diagnose this further when it happens again. May
be a driver issue, too. Some months ago I could not use sleep because after
wakeup the network interface wasn't usable - it just died. Restarting
NetworkManager did not fix it either. I had to manually use ifconfig up/down
or maybe ethtool to force the link back up - I do not remember. Some
googling told me it may be a firmware-related issue and was supposed to be
fixed with some newer firmware I had to download from RealTek. Sadly, it
didn't help. Meanwhile, this works reliably. Just except in this case...
>> But what actually results from this is the following question: How do I
>> prevent systemd from trying to go to sleep while the backup job is
>> running? I'd like it to either (a) do not go to sleep at all (do not even
>> try) or (b) defer the sleeping signal until the backup job finished, with
>> (b) preferred plus some grace time.
> See systemd-inhibit(1).
Yeah, I've read that of course. Maybe I didn't get the complete picture but
from the man page it's supposed to work by running systemd-inhibit on the
command line. This in turn means, I'd need to place ExecStartPre and
ExecPostStop hooks in the unit file. This seems wrong to me as this had
nothing to do with the actual process being executed. I expected to find
something like placing "Inhibits=sleep" in the unit file which would look
more natural to me in the spirit of how systemd units work. So I didn't try
that yet and thought I'd better ask here first.
>> I don't know if something like "Conflicts=sleep.target" would do the job,
>> I even do not know if that would be a good idea at all.
> This wouldn't be a good idea because your job would get cancelled as a
> result of sleep.target/start.
I suspected that... Thus why I felt it's a bad idea.
>> Ah, and then another one, more or less unrelated: Lennart one time told
>> me that it's on the feature plan for systemd to wake the system up for
>> selected timer units and put it back to sleep afterwards. It would be a
>> nice-to-have. Still on the feature list? Maybe any news on that? I'd like
>> to test it.
> Nothing so far.
What a pity. Are there any deeper plans on that one? I think it should not
be too difficult to implement and if I had some time I would try it. But I
don't like inventing all the complex surrounding this may bring in, read as:
Is there a list / brainstorming of what one had to consider and take care
of? While documentation of systemd is very good and easy to follow, I find
it difficult to find documentation of implementation details and feature
plans (yes, there are the blogs but those seem to cover thoughts about
already implemented features)...
>> Another one, partially unrelated: I've set up the backup mount point with
>> automount in systemd (via fstab). Is it possible to automatically undo
>> that automount upon finishing the backup job? If I explicitly call
>> umount, the job could wait forever if I accidently left a shell open in
>> that directory. This more or less concludes to the question: Could
>> automount units also automatically unmount after some idle time (after
>> nothing any longer accessed the volume)?
> It's in the TODO...
Replies to list only preferred.
More information about the systemd-devel