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

Mirco Tischler mircotischler at gmx.net
Tue Feb 11 17:48:29 PST 2014

Am 12.02.2014 01:31 schrieb "Kai Krakow" <hurikhan77 at gmail.com>:
> Hey there!

> I've got a daily backup job scheduled using a timer unit and a oneshot
> service file. This backup takes around 2-4 hours. It's using rsync and
> from btrfs HDD to a snapshotted btrfs on USB with inplace deltas. I'm
> mentioning this because it may matter.
> I've also set my system to auto-sleep after 4 hours of idle time. This
> means, in KDE I've set the option to put the system to sleep after that
> of inactivity.
> This usually works fine. But sometimes during backup, the system cannot
> sleep. I see it still powered fully on the next morning. In dmesg, a lot
> btrfs and blockdev related tracebacks accumulated with notes of being
> to sleep because a processed has refused to stop. I don't know if this is
> btrfs-related or not - but actually I don't think it's wise to go to sleep
> while the backup process is still running either.
> 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).
> 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
> I'd like it to either (a) do not go to sleep at all (do not even try) or
> defer the sleeping signal until the backup job finished, with (b)
> plus some grace time.
> I don't know if something like "Conflicts=sleep.target" would do the job,
> even do not know if that would be a good idea at all.

It's late here so excuse me if I'm missing something. But wouldn't a simple
Before=sleep.target suffice to implement b)?
If your backup job is still running it blocks sleep.target's start until it
Though for the grace period some ugly hack such as
"ExecStartPost=/usr/bin/sleep <n>" would be required.

> 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
> timer units and put it back to sleep afterwards. It would be a
> Still on the feature list? Maybe any news on that? I'd like to test it.
> Another one, partially unrelated: I've set up the backup mount point with
> automount in systemd (via fstab). Is it possible to automatically undo
> 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
> 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)?
> --
> Replies to list only preferred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140212/7136dd7c/attachment.html>

More information about the systemd-devel mailing list