On Sun, 2013-11-03 at 16:06 +0100, Kay Sievers wrote: > On Sun, Nov 3, 2013 at 3:36 PM, Bastien Nocera <[email protected]> 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
