[systemd-devel] How to prevent sleep during running oneshot units
hurikhan77 at gmail.com
Wed Feb 12 14:41:37 PST 2014
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.
More information about the systemd-devel