Often this is already implemented by conditions on the service unit, e.g. plocate-updatedb.service has [Unit] ConditionACPower=true, so although the timer will try to activate it every midnight (per its OnCalendar=daily), it'll be *quietly* ignored if the machine is on battery.
"Being online" though isn't really something that can be expressed as a direct condition... except perhaps ConditionExec. Systemd (as in the core service manager) has so far tried to delegate that decision to the various network management tools instead, since there's no single "online" state that everyone can agree on. I guess you can try to make the case for ConditionIPv[46]DefaultRoutePresent though... (GitHub Issues is the place for specific feature requests) On Mon, Dec 29, 2025 at 9:20 AM doskel <[email protected]> wrote: > Evening, all. I'm unsure of if this is the correct place to ask, so if > there's somewhere else I should go just let me know. > As of late I've been roughing out a concept for an additional type of > timer that would trigger on certain targets or system states; something > like defining a job to run backups that is configured to run as part of > a "sync" state, defined by the user, that could require a specific > timeframe (midnight, for example), being online, and the machine being > charging. > This would mostly be useful for mobile devices on batteries, but could > also be used to run heavy jobs during periods of low resource usage on > desktops or servers. > Similar results could likely be gotten using a bunch of Requires= > hooked to system targets, but broadly I feel that more system > environment constraints would make it much more elegant and the overall > architecture more comprehensible. > If this would be acceptable as part of systemd, I'd be happy to make a > draft PR for it and start taking comments, but if it's out of scope or > something that should just be done with shell scripts that's > understandable. > > -doskel >
