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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 12, 2014 at 02:12:15AM +0100, Kai Krakow wrote:
> 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.

On Wed, Feb 12, 2014 at 06:55:38AM +0400, Andrey Borzenkov wrote:
> No, you need to wrap your command with it. I.e. instead of
>
> ExecStart=/path/to/backup-command ...
>
> you use
>
> ExecStart=/usr/bin/systemd-inhibit /path/to/backup-command ...
Right. Not too bad, but Inhibits=sleep sounds nice.

> >> 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)...
Yes, it seems that basically changing the timer type would do the trick.
One thing which worries me, is the issue the "laptop in the bag" issue.
But maybe we would just need to document the fact that setting the timer
to need to make sure that the computer will not be in hostile surrounding.
OTOH, it might make sense to add a new inhibition: 'alarms',
which you could set *before* suspending, which would prevent CLOCK_REALTIME_ALARM
timers from firing.

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

Zbyszek