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

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Tue Feb 11 16:40:40 PST 2014

On Wed, Feb 12, 2014 at 01:30:59AM +0100, Kai Krakow wrote:
> Hey there!

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

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

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

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


More information about the systemd-devel mailing list