Just learned of timers the other day, but I’m a cron guy, anybody out there using timers? Anything I’m missing out on?
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.
This is the only case in which I use timers, really, when I want something to run on startup, every once in a while, but only after it’s confirmed that the internet is up.
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.
Much more control and integration. Randomization without tricks. Dependencies. Just a few things I used last.
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.
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.
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.
My system has timers, but I use cron anyway. It’s more simple, IMO.
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.
