On 5/1/2021 10:52 AM, Lénaïc Huard wrote: > The existing mechanism for scheduling background maintenance is done > through cron. On Linux systems managed by systemd, systemd provides an > alternative to schedule recurring tasks: systemd timers. > > The main motivations to implement systemd timers in addition to cron > are: ... Thank you for working on this. Users have questioned "why cron?" since the release of background maintenance, so I appreciate you taking the time to port this feature to systemd. I won't do a deep code review here since that seems to already be covered, and a v2 seems required. Ensuring that users can choose which of the two backends is a good idea. We might even want to start with 'cron' as the default and 'systemd' as an opt-in. The other concern I wanted to discuss was the upgrade scenario. If users have already enabled background maintenance with the cron backend, how can we help users disable the cron backend before they upgrade to the systemd version? I imagine that we should disable cron when enabling systemd, using crontab_update_schedule() with run_maintenance given as 0. We might want to enable quiet errors in that method for the case that cron does not exist. It is important to make it clear that we only accept one scheduler at a time, since they would be competing to run 'git for-each-repo' over the same list of repos. A single user cannot schedule some repositories in 'cron' and another set in 'systemd'. This seems like an acceptable technical limitation. Thanks, and I look forward to your v2! -Stolee
