Mirco Tischler <mircotisch...@gmx.net> schrieb: > It's late here so excuse me if I'm missing something. But wouldn't a > simple Before=sleep.target suffice to implement b)?
I'm not sure... The unit is not enabled, only triggered by the timer - so it may work. I think I may try that as an alternative to systemd-inhibit. Systemd-inhibit just does not feel like the right tool for this. > If your backup job is still running it blocks sleep.target's start until > it finishes. Then, what happens if I start using my system during backup, sleep.target had been triggered but is waiting for the backup job to finish? Will it simply go to sleep then while I am using the system? OTOH, will systemd- inhibit cover that case? Twisted around: What happens if sleep is triggered by the system due to idle time while sleep is inhibited? Will it trigger as soon as the inhibit is removed again? Or will the idle timer for my system just trigger sleep again after it has passed a second time? > Though for the grace period some ugly hack such as > "ExecStartPost=/usr/bin/sleep <n>" would be required. My primary concern here is btrfs doing a lot of background work when handling snapshots. My backup medium is a btrfs with rsync copying the source as in-place deltas to a scratch area, then taking a snapshot of it. Later, I'd like to automatically cleanup old snapshots - but that means I should wait before going back to sleep until btrfs finished that job. A simple "sleep" probably won't do. I suppose it would require an option like "--wait" to "btrfs subvolume delete", then wait another 5 minutes to give all pending write commits a chance to make it to disk. -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
