[systemd-devel] Power aware units

[Bastien Nocera]

On Sun, 2013-11-03 at 16:06 +0100, Kay Sievers wrote:
> On Sun, Nov 3, 2013 at 3:36 PM, Bastien Nocera <hadess at hadess.net> wrote:
> > 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/
> >
> > 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.
> > - systemd ships a set of units that UPower will launch/stop based on
> > battery status. This would require UPower to know more about some other
> > subsystems as well such as the lock screen status, or the hard drive
> > state.
> >
> > This would be useful for things like backups, housekeeping (emptying old
> > files from the trash, old thumbnails, etc.), launching update-db, etc.
> > in addition to the simple timer intervals.
> >
> > I think the first option is the best one, as in addition to UPower, we'd
> > need to talk to the kernel/udev (HDD spinning state), and logind (lock
> > screen status).
> 
> Systemd should not get any direct or indirect dependency on upower for
> primary service management tasks. It just doesn't sound right to do
> dependencies in this direction.

That doesn't strike me as as crazy as it may seem. systemd would only
monitor a couple of properties on a remote D-Bus name. If the name isn't
present, use defaults (not on battery, not discharging, HDD spinning).

> If systemd needs more information than the current on-battery vs. AC,
> we would need to add that to systemd itself, or even add support for a
> "virtual/composite battery" to the kernel.

That would leave policy handling (eg. what's low-battery?), and UPS
support on the wayside. I also don't think you want to start polling
batteries in systemd.

> > In addition to that, would it make sense for distributions to start
> > porting their cron jobs to use systemd?
> 
> This all sounds nice to have, and what we want to have in the longer
> run. We could do most of that already today, with just the battery/AC
> information, I think.

I think it's all or nothing. Merging batteries is a crappy enough job
(with work-arounds for bad firmwares) that you really don't want it in
the kernel or systemd itself.