systemd.timer
This article about systemd timers made it to the front page of Hacker News today. I always get a little bit upset when I see documentation or advice that talks about defining a cron job, as if cron is the only way of scheduling tasks. Cron served us well, but if you know what cron and systemd are you should read the documentation for systemd timer units.
This:
OnCalendar=Thursday 18:00 Australia/Melbourne
Is so much nicer than:
0 7 * * 4
Now I will conceded that as with most of the components of systemd, the manuals don’t make it very easy to discover all the magical things you can do with unit files, but the few minutes I took several years ago doing just this have saved me way more time since then.
Bonus tips: systemd-analyze calendar
is a cute little tool to know about too:
$ systemd-analyze calendar "Thursday 18:00 Australia/Melbourne"
Original form: Thursday 18:00 Australia/Melbourne
Normalized form: Thu *-*-* 18:00:00 Australia/Melbourne
Next elapse: Thu 2025-03-20 07:00:00 UTC
From now: 6 days left
Plus! systemctl list-timers
gives you a nice list of loaded timers with human-readable “last run” and “time to next run”, and systemctl status timername.timer
works as you’d expect as well, including a tail of the output of the last run. You get all of that for free because the timers trigger regular systemd units, which in turn means (by default) output gets sent to the systemd journal. It also means you can manually trigger the same unit at any time and know it will behave the same whether run by a timer or not.
Way better than cron. Fight me.