Systemd timer units don't have much appeal for us (over crontab entries)
I recently wrote about when out crontab entries run, and in a comment Joseph asked if we'd considered switching toward systemd timer units instead. The short answer is no; the longer answer is that unlike Joseph's experience, we don't think we'd find timer units to be a significant improvement over the old, well understood crontab approach.
So let's start with the good things about systemd timer units as
compared to /etc/cron.d
, which as I see it are two-fold. First,
systemd timer units provide an easy way to execute the actual
'crontab' command on demand; since they require an accompanying
unit to activate, you can just 'systemctl start <unit>
' and be
done. This beats looking at your /etc/cron.d
entry to pull out
the command, and as a bonus it automatically gets the user right,
if you're running the command as a non-root user. Second, systemd
timer units provide more flexible timing for periodic activities
than crontab entries do (and can have built in randomization of
start times, which is important across a fleet). Crontab entries
need to divide relatively evenly into crontab units, and they don't
go to finer grained units than minutes. If you want something
activated every 90 seconds or every 13 minutes (for two examples),
using cron is going to be painful.
The great advantage of crontab entries in a modern environment that
supports /etc/cron.d
is that they're much simpler to deploy and
use. With crontab, you need one simple file that you put into a
single directory and then everything is deployed and active, and
you will automatically get mailed any (error) output so you know
about problems. With systemd timer units, you need at least two
more complex files (a .timer and a .service file), you need to run
an additional command on deployment (to enable the timer), and
being emailed anything when the timer fails is more complicated. In addition, both the systemd files have
to go into an increasingly cluttered directory that's used for all
sorts of assorted purposes (ie, /etc/systemd/system), while crontab
entries go into a directory that's specifically for this purpose
(/etc/cron.d) and so is easier to keep track of.
A single crontab file can also have multiple related activities in it, such as 'everything we do frequently on our ZFS fileservers'. With systemd timers, each timer unit can only control a single command, because it triggers exactly one other systemd unit. This can increase the number of files and deployment steps you need, and also opens the door to mistakes like a partially enabled set of timers (or, on the flipside, a partially disabled set of them; with cron.d, you can 'disable' everything in a group by removing the file).
For us, the systemd timer advantages aren't important. We rarely
want to run crontab commands by hand, and we don't have anything
we want to run that doesn't fit within the constraints of crontab
scheduling. By contrast, we do get value from the simpler deployment
for crontab entries in an /etc/cron.d
environment (and also from
/et/cron.hourly
and /etc/cron.daily
).
In theory, /etc/cron.d
is somewhat more universal across Linux
environments. In practice systemd has won these days so systemd
timer units are as available on any Linux distribution we're likely
to use. They're certainly as available on Ubuntu LTS, and in practice
we are essentially an Ubuntu
LTS shop these days.
(We still have some CentOS 7 systems, but since IBM took CentOS 8 out behind the barn and shot it, they will be replaced with Ubuntu machines in the future.)
Comments on this page:
|
|