[systemd-devel] Power aware units

[Lennart Poettering]

On Sun, 03.11.13 15:36, Bastien Nocera (hadess at hadess.net) wrote:

> Heya,
> 
> systemd already allows launching specific tasks based on a timer, and
> intervals, and I was wondering whether power awareness was something
> planned for launching and stopping units.
> 
> MacOS X 10.9 has some additional metadata for units that allows launchd
> to stop and start particular tasks based on power levels:
> http://arstechnica.com/apple/2013/10/os-x-10-9/16/

So, hmm. So far our policy on Linux was mostly "If something good for
battery cases, then it is good for AC cases too", i.e. the dichotomy
between services that may run on battery and that may not be run on 
on battery is not necessarily a good one.

I am really wondering hence whether policies like this one really should
exist at all? And to figure that out we probably should look closely at
the usecases. So, what are the use cases?

You listed:

- backups
- tmpfiles/cache ageing (including trash expulsion, thumbnail cleanup)
- update-db

And I figure other ones to add here are:

- mandb cache cleanups
- rotation of legacy log files

(are there more usecases you can come up with?)

All these are exclusively cronjobs, i.e. services triggered only by
time, and nothing else. And all of these strike me as things where we
really should run them on battery too, as not doing them at all will
sooner or later have a negative effect on the stability and safety of
the system.

So, thinking about this I have the suspicion all that we really can do
is modulate the timers a bit: i.e. if the system is on battery
power simply lower the frequency how often we dispatch timer
events. More specifically: what about adding a new option for .timer
units maybe called "BatterySlackSec=" or so, where you can specify some
extra time the execution of the job can be delayed for at maximum if the
machine is on battery. If it is not on battery we'd ignore this
value. If the machine changes from "on battery" to "on ac" we'd
immediately execute all services which are already in their "battery
slack" phase. This would then allow people to easily express things like
"Clean-up /tmp every day, but if I am on battery delay it for another
day at max, and possibly exeucte it immediately if I replug power". Or
something similar.

So, would this make sense to you? Is there anything this logic wouldn't
cover?

(Oh, and also note that there actually already is ConditionACPower=
which allows you to skip execution of certain services if AC is plugged
in/is not plugged in. See systemd.unit(5) for details).

> We could implement this in 2 ways:
> - systemd itself speaks over D-Bus to UPower (using the new
> DisplayDevice to merge UPS and batteries) and stop/starts the units.

I am a bit afraid of making systemd depend on external daemons for
things like this. Making systemd a client to another service that is
started by systemd, is always problematic, due to potential deadlocks
and cyclic deps. We are currently working on getting rid of a dependency
like this in regards to dbus-daemon where kdbus makes this all nice and
clean for us, and I'd really prefer not to add another case like
this... 

I don't even think this would be necessary really. The power source
kernel device class is sufficiently simple for us to use directly, going
via upower doesn't appear necessary (I mean, for this logic we don't
need battery states of mice and suchlike, hence this shouldn't be a
problem.)

> In addition to that, would it make sense for distributions to start
> porting their cron jobs to use systemd?

It certainly would make sense, but my plan was to first add a couple of
things to our timer logic implementation that is substantially better
than classic cron so that we have strong case to make why people should
adopt it. However, never found the time to work on this.

Lennart

-- 
Lennart Poettering, Red Hat