Just learned of timers the other day, but I’m a cron guy, anybody out there using timers? Anything I’m missing out on?
Automatic failure handling, advanced logging, independent execution environment control, cgroups support, service dependency management…
On the negative side, it takes slightly more work to configure timed tasks and there’s no integrated email support.
Refer to the Arch Wiki for more detailed information.
Email support was the bain of my existence. I forgot how many misconfigured system I came across decades ago that would fill up their filesystem with logs from crons in the root mail dir. Such a stupid default setting. We have vastly better methods for monitoring systems these days then firing off an email when a cron runs.
Automatic failure handling, advanced logging
Dam the first 2 already got me wanting to switch lol
And as I just recently learned, network namespaces support! Those can be handy if you need a backup job to route through a VPN tunnel, or some such thing.
My number one reason for using systemd timers is just that I find it more readable than cron. Usually I want to run things
daily,weeklyormonthlyand systemd timers make that very easy.Here is an example:
backup.timer
[Unit] Description=Run backup database daily [Timer] OnCalendar=daily RandomizedDelaySec=10 [Install] WantedBy=timers.targetbackup.service
[Unit] Description=Backup database [Service] Type=oneshot ExecStart=/bin/bash /path/to/backupscript.shAnother great feature is that the output of the script is logged to journald which is very convenient when you are troubleshooting why your backup failed last night.
You can also easily see when the job last ran, if it was successful and when it will next run. As well as just trigger the service if you want it to run now.
Usually I want to run things
daily,weeklyormonthlyand systemd timers make that very easy.While
crontabalso has keywords for@daily,@weeklyand@monthly, the automatic logging ofsystemdis useful and your example shows that it additionally allows to specify delays. I don’t know howanacronhandles the latter.
Also a cron guy, but systemd timers can do things like run at a preset time after start up if a schedule was missed due to power off or system suspension, and you can get more information about a failed timer with journalctl. Arch wiki has lots of good info. Still, I’m a cron guy. 🤷♂️ Set in my ways
Are you unaware of anacron?
You can do the same with cron btw depending on the OS(?). At least on debian systems. I think its
@poweroffor@rebootif I recall correctly.It’s more than just power state, you can also toggle based on the state of other units (which you could chain normally too, but not time based) so you could start a service 10 minutes after another service has ran to completion, or after it’s died, etc.
If you already know cron and are too lazy to learn something new, then use cron with the knowledge that it’s a personal failure and not a real technical decision… Otherwise, use systemd timers.
I was literally just pondering this. I’ve got a local backup job that is a very simple rsync command which I originally setup as a cron job. I’ve got a cloud backup job I setup later with systemd timers. I went to add a new backup job and had to decide which to go with.
There is absolutely still a place for the cron jobs. If you are aware of it’s limitations it cannot get simpler than a new /etc/cron.d/ file with a single line. But the systemd timer path offers some nice functionality in exchange for a tad more complexity and less footguns. Whichever one you understand the best is probably the best answer.
I am using timers for some time now, because systemd timers are included and I don’t have any good reason to install a cron also.
Much more control and integration. Randomization without tricks. Dependencies. Just a few things I used last.
For me ive always used:
- cron if its simple and can take care of itself.
- systemd if its more complex and needs the OS to do a thing related.
Its not a hard set rule but its like 95% cron and some systemd on the side for me.
The entirety of
crondocumentation is contained in the twenty lines of comments in the new config file created bycron -eThe only thing you need to know is
cron -ecommand. There’s no learning curve, it’s more like - you are acronexpert in five minutes after learning that such a tool exists.
