[systemd-devel] How to prevent sleep during running oneshot units

[Kai Krakow]

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

Nice.

-- 
Replies to list only preferred.