Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 11:25:56AM -0800, Russ Allbery wrote:
> > As a third party with no particular ax to grind on this, I do wonder
> > what the advantage is to adding another mechanism for this particular
> > use case, given the need to somehow handle upgrades involving an
> > existing (presumably working?) solution.
>
> Timer units allow the administrator to easily enable and disable them
> without mucking around with changing configuration files and then dealing
> with merging changes to configuration files. (I just had to deal with
> this with a spamassassin upgrade as part of upgrading to the latest
> stable.) They also handle suspended systems, time changes, and other
> related things better than cron jobs (anacron helps with some of that, of
> course).
It's also quite a bit easier for an admin to adjust the period of a
systemd timer than it is for a cron.daily script.
cron.daily scripts are also run serially. The random delayed start
feature that the spamassassin job uses to reduce load on the sa-update
servers doesn't really play nicely with this, as it ends up delaying the
start of subsequent jobs for no good reason. We could avoid this with
cron.d, and as has been pointed out elsewhere in this thread, that might
be desirable anyway, but that's still a migration that is going to be
visible to administrators. IMO the migration to systemd timers can be
done more smoothly, so it's still preferable.
The big drawback of systemd timers, IMO, is that a nonzero exit code
doesn't generate email by default the way cron does. At smaller sites,
anyway, this is a perfectly sensible way of being notified of problems
with the job.
noah
Reply to: