I could be missing something, but I think there's a gap in the functionality for timers for periodic tasks on battery-powered devices. Basically, I want to generate a security report (SCAP style) approximately weekly but avoid doing so on battery.
Here's what I've tried or looked at:
- If I use ConditionACPower=true on the Type=OneShot service performing the task, then systemd will not run the task while on battery, but it still resets the timer. With a longer _OnCalendar_= interval, there's a significant chance that the infrequent check will overlap with battery-mode operation, causing the task to never run.
- If I use ConditionACPower=true on the timer, then the timer just won't start if the machine boots on battery. This is also undesirable, as a machine may only boot every few weeks.
- _OnActiveSec_= doesn't support persistence, so intervals of approximately a week may never fire on some laptops that shutdown or reboot frequently.
- _OnBootSec_= would be too frequent for laptops that shutdown or reboot frequently.
It seems the best I can do right now is use a shorter timer interval with no AC power condition but have the Type=OneShot service exit early if it last ran too recently, especially if currently on battery power. I'm also looking at just using anacron.
What I would prefer is a [Timer] option like AvoidOnBatterySec= that causes the timer to avoid firing on battery yet fire on restoration of AC power if overdue. If the AvoidOnBatterySec= duration has elapsed since the last firing, the timer fires regardless of whether the device is on battery. This would allow easy configuration of periodic tasks that are power-hungry but need to run eventually. Some of our laptops rarely run on AC aside from when they're closed at night.
I would even consider a directive like WakeSystemSec= that specifies a maximum interval that must elapse since the timer last fired before waking up the system to fire the timer. Similarly to AvoidOnBatterySec=, it would serve as a way to get more aggressive if a periodic task is too far overdue.
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
