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

[Kai Krakow]

Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> schrieb:

>> 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 probably try that, thou I'd prefer an extra configuration option for it 
because in the jobs monitor it would show me systemd-inhibit as the running 
process instead of my backup script.

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

Your "laptop in a bag" example is that kind of brainstorming I was thinking 
of. Of course, such an option to resume from sleep should always be opt-in, 
never opt-out. So, if we had such a new timer type, systemd should have a 
switch to actually behave this way and default to fall-back behavior (not 
waking the system). That way, an energy profile in desktop environment could 
control this switch: Set your profile to "desktop" and it will opt-in to 
wake timers, set it to "laptop" or "mobile", and it won't opt-in. If battery 
is below some threshold it sould also not opt-in. My use case is a desktop 
PC so I didn't think of such issues.

I don't like the fact to solely rely on an inhibition "alarms" because that 
would means it'd be opt-out only. In my opinion it needs to be opt-in.

-- 
Replies to list only preferred.