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

[Kai Krakow]

Mirco Tischler <mircotischler at 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?
>>
> Yeah, the job to start sleep.target will still be active, so this should
> only work for overnight stuff.

So that is no option... Sometimes I'm a hacker and start using my PC at 
night... ;-)

>> 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?
>>
> Systemd-inhibit has the options block and delay for this. But when and if
> the idle time gets restarted is up to the idle timer ;-)

Then this is the way to go until better options are available.

>> 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.
> Sounds like you want systemd-inhibit for both your backup service and the
> btrfs subvolume delete 'service'. And the kernel will call sync() before
> suspending, shouldn't that suffice?

Apparently not... A btrfs subvolume deletion is something handled by a 
separate kernel thread - a sync won't wait for it to finish. I tried it, did 
not work out. This in turn means, the pending transactions of deleting each 
subvolume will be aborted if the device is resumed inproperly (e.g. by 
rebooting the system instead of resuming, or detaching the USB device and 
reattach it at another PC). The subvolumes will simply reappear then. When I 
had such situations by accident, it did no harm, however. The btrfs was 
intact, it cleanup up some orphans and just worked, with the directory 
entries there again. So it seems pretty stable in that regard. But I don't 
like directory entries to reappear which were already gone since maybe hours 
(depending on how many snapshots you deleted).

I'm still not sure if btrfs subvolume delete should be another service... I 
probably would start it in a subprocess of the backup job while it is 
running and delete a snapshot one-by-one until I'm above a certain threshold 
of free space again (or below a certain threshold of snapshots to keep). 
This also requires to be able to wait for each process. Btrfs does not allow 
that yet.

-- 
Replies to list only preferred.