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.
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.
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, weekly or monthlyand 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.
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.
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.