[systemd-devel] Power aware units

[Bastien Nocera]

On Mon, 2013-11-04 at 15:27 +0100, Lennart Poettering wrote:
> 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.

Those _were_ all cron jobs. I don't think that any of those should be
cron jobs, especially the 4 AM update-db or man-db runs. Anacron is just
patching over the fact that most machines aren't running at that time of
day.

Automatically installing application updates is another use case, or
tracker indexing files. Basically, anything that runs in the background
without direct user interaction.

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

I don't think that update-db or man-db should be updated when on
battery, and even less when on low battery.

It also shouldn't wake up the hard disk, or be run when I have
interactive tasks on-going (eg. it should run when the screen lock is
on, not in the middle of streaming a film).

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

You want backups to run when on AC and the screen is locked (or even
better, when the machine is supposed to be sleeping, with the lid closed
for laptops).

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

It doesn't include UPS status, it doesn't know when the hard disk is
sleeping, it doesn't know when the screen lock is on.

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

It's not, because you're missing information about low batteries (eg.
that's a policy in UPower, which I don't think you are or should be
replicating in systemd), and about UPSes.

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

Do you have a list of what's missing?

The benefit in adding usage classes (as Apple did), rather than tweaking
each background task manually is that it makes it easier to change the
policy for running those, and affect all the uses of that class.

I would think that backups, man-db or update-db runs would automatically
get the lowest CPU and I/O priorities as possible, you'd mark some of
them as easily disposable/interruptible if RAM was scarce.

So I don't think that systemd's current "on AC" is sufficient to express
all the power saving policies we want to apply to background tasks.

Cheers