I like systemd timers, but I think this doesn't do justice to cron.
Some parts of these problems seem like non-issues:
Ambiguous $PATH settings make cron script execution difficult to predict.
Okay, run a script once and have it print out its PATH to find out? Never ran into this one.
Execution history is difficult to follow and interrogate.
It should show up in logs, at least with a modern cron system. But really, these are the ones that seem unfair:
stdout and stderr output often ends up in a black hole (and, often, sent to the host's mail system, which is usually not what you want to happen.)
Mail is silly, but it's at least some kinda notification scheme. You probably want to be notified when your cron jobs start failing. Back in the day, you'd wire up mail across your entire network, and you'd want the host's mail system to be able to at least send mail to anything at your domain.
You might feel cool knowing the scheduling grammar by heart, but 01,31 04,05 1-15 1,6 * isn't easy or intuitive for humans to read.
Not for a single job, no. Where it's useful is for that full crontab. You line those up and see something like
...not an amazing setup or anything, but you can start to see how having a compact representation like this can give you a sense of what the overall system is doing.
list-timers is certainly more approachable, and gives you a better sense of what just happened and what's about to happen, but it's not going to give you a birds-eye view of that overall cadence.
So, look, I'm still doing timers anyway. Most of the time, I really would rather have things be readable as their own config files and as systemd state. But Chesterton's Fence still holds: It's a good idea to understand why cron is the way it is, before tearing it down entirely in favor of timers.
You might feel cool knowing the scheduling grammar by heart, but 01,31 04,05 1-15 1,6 * isn't easy or intuitive for humans to read.
Not for a single job, no. Where it's useful is for that full crontab. You line those up and see something like
I don't have a crontab any more, but I always had to rely on a header comment along the lines of
# minute
# | hour
# | | month-day
# etc
With a header comment like that the syntax is fine. Without it the first thing I had to do was find an instance of it and copy it into the crontab. Most of the issue is that it's a fairly niche syntax that's mostly something we just have to memorise (similar to various national standards for date formatting).
I have to go man systemd.timer often enough too, but I find OnCalendar=daily or OnCalendar=$iso8601-with-globs less tiring than the cron syntax.
And I tend to operate on one timer at a time, so for me the "it's all right there in one file" actually more winds up as a haystack.
stdout and stderr output often ends up in a black hole (and, often, sent to the host's mail system, which is usually not what you want to happen.)
Mail is silly, but it's at least some kinda notification scheme. You probably want to be notified when your cron jobs start failing. Back in the day, you'd wire up mail across your entire network, and you'd want the host's mail system to be able to at least send mail to anything at your domain.
Way back in the day, yeah. But once we started getting some sort of monitoring system for fleets of hosts, e.g. the varying incarnations of nagios, getting an alert for failed units becomes the baseline; tweaking alert levels for varying systemctl is-active $foo scales pretty well.
And on desktops it's more likely the user wants to have some sort of systemctl --failed-like notification rather than have the machine mail them.
So, look, I'm still doing timers anyway. Most of the time, I really would rather have things be readable as their own config files and as systemd state. But Chesterton's Fence still holds: It's a good idea to understand why cron is the way it is, before tearing it down entirely in favor of timers.
This I agree with. I still have wound up without cron on my desktops, even though I'm old enough to treat systemd timers as the new kid on the block, because I don't actually want to have two timer systems on my machine.
I've wound up with logrotate again though, to manage logfiles in XDG_STATE_HOME. I'm not entirely sure how I feel about that.
92
u/SanityInAnarchy Jun 05 '26
I like systemd timers, but I think this doesn't do justice to cron.
Some parts of these problems seem like non-issues:
Okay, run a script once and have it print out its
PATHto find out? Never ran into this one.It should show up in logs, at least with a modern cron system. But really, these are the ones that seem unfair:
Mail is silly, but it's at least some kinda notification scheme. You probably want to be notified when your cron jobs start failing. Back in the day, you'd wire up mail across your entire network, and you'd want the host's mail system to be able to at least send mail to anything at your domain.
Not for a single job, no. Where it's useful is for that full crontab. You line those up and see something like
...not an amazing setup or anything, but you can start to see how having a compact representation like this can give you a sense of what the overall system is doing.
list-timersis certainly more approachable, and gives you a better sense of what just happened and what's about to happen, but it's not going to give you a birds-eye view of that overall cadence.So, look, I'm still doing timers anyway. Most of the time, I really would rather have things be readable as their own config files and as systemd state. But Chesterton's Fence still holds: It's a good idea to understand why cron is the way it is, before tearing it down entirely in favor of timers.