A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
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.
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.
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.
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, weekly or monthlyand 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.target
backup.service
[Unit]
Description=Backup database
[Service]
Type=oneshot
ExecStart=/bin/bash /path/to/backupscript.sh
Another 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.
Usually I want to run things
daily,weeklyormonthlyand systemd timers make that very easy.
While crontab also has keywords for @daily, @weekly and @monthly, the automatic logging of systemd is useful and your example shows that it additionally allows to specify delays. I don't know how anacron handles the latter.
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.
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 @poweroff or @reboot if 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:
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 cron documentation is contained in the twenty lines of comments in the new config file created by cron -e
The only thing you need to know is cron -e command. There's no learning curve, it's more like - you are a cron expert in five minutes after learning that such a tool exists.