Re: migration from cron.daily to systemd timers

[Josh Triplett <josh@joshtriplett.org>]

Noah Meyerhans wrote:
> 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?

That sounds like the correct approach. We should not have scripts that
run just to check a configuration variable and see if they should
immediately exit; disabled services should be *disabled* and not run at
all.

(I would suggest doing the same for the cron job, for new installations:
put the script itself in /usr/lib/spamassassin or similar, and document
that people can enable it by either enabling the systemd timer, linking
the script from cron.daily, or copying the script to cron.daily if they
really want to modify it.)

> 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?

I've seen multiple discussions about updating Debian's version of cron
to a newer version/fork, which includes support for handling this
internal to cron, just as systemd avoids running an init script if a
corresponding service exists. That seems vastly preferable to individual
scripts waking up periodically and performing such a check. I would
suggest checking with the cron maintainers regarding the status of such
work.