Chris Siebenmann recently posted an article on his excellent blog titled, “Systemd timer units have the unfortunate practical effect of hiding errors“.
I posted a comment in reply:
Switching from cron to systemd timers is definitely an operational change.
The emphasis on emails feels like status quo bias, though. Imagine the situation was reversed: that everything was using systemd timers and then someone wrote cron and people started switching to that. In that case, there is a similar operational change. You’d switch from having a centralized status (e.g. systemctl list-units --failed
) and centralized logging (the journal, which also defaults to forwarding to syslog) to crond sending emails. Is that an improvement, a step backwards, neither or both? Either way, I’d say the most important thing is that you need to integrate the new tool into your environment.
FWIW, at my work, we are in the process of converting all of our cron jobs into systemd service and timer pairs. One of the big reasons for that is that we already have systemd failed units monitored by Icinga, so this eliminates a separate way of monitoring things (emails to root) in favor of our unified alarming system. Also, emails are not great if an “every minute” or “every five minute” cron job starts failing.
We also expect other advantages. For one, service units are easier to develop & debug, as you can just start them with systemctl
, without having to fiddle with the cron definition to run it at “the next minute” and then remember to change it back to the production timings when you’re done. Also, systemd timers can be randomized to spread the load rather than having every system wake up at the same moment and start running e.g. daily jobs. (I’m aware that cronie has RANDOM_DELAY
, but Debian & Ubuntu still use Debian’s vixie-cron which does not.)
Time will tell if this was a good idea or not. Assuming this goes well for us, the next phase will be to switch from crond to systemd-cron, a (third-party) systemd generator that creates service and timer units from crontabs. This will dynamically convert any package cron jobs.
If emails are what you want, systemd timers are definitely a step backwards in that regard. Emails can be done, and systemd-cron has a setup for them for the units it converts, but it is additional work. And for timer-triggered services that are provided by distro packages (i.e. not you), while you can use drop-in config files to add the relevant configuration, you have to do that per-service. This is extra work, and more importantly, you have to know about all such units you have installed, which does not scale.
Another, more general, option would be to wire up something to check for failed units and send an email based on that.