Spamassassin has traditionally supplied a cron.daily script. I'd like to provide the same functionality via a systemd timer, while still providing cron as a fallback. For the most part, this is straightforward, but there are a few details on which I'd like feedback.
Current the cron.daily script is a no-op by default, and functionality is enabled by setting CRON=1 in /etc/default/spamassassin. For users running systemd, I'd expect to ship a timer unit that is disabled by default, and have them enable it with: $ systemctl enable spamassassin-daily-maintenance.timer Any issues with that? For upgrades from versions that did not include the timer, should I enable the systemd timer if the user has set CRON=1? Or should I leave the timer disabled and preserve the original behavior via cron.daily? Since the cron script is a conffile, and may have local modifications, I think it should be left in place, but would take confirmation. It'd be possible to perform the migration while still preserving local modifications, e.g. by having the shipped cron script enable the unit file, but IMO that would be gross. If the timer and the cron activity are both enabled, the cron script will be a no-op. This is accomplished with the following in the cron script: if command -v systemctl > /dev/null 2>&1 && systemctl is-enabled spamassassin-daily-maintenance.timer; then exit 0 fi Would you do this a different way? noah