Straight from the horse's mouth, so to speak: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement
An excerpt from the page above:
Benefits
Benefits
The main benefits of using timers come from each job having its own systemd service. Some of these benefits are:
The main benefits of using timers come from each job having its own systemd service. Some of these benefits are:
- Jobs can be easily started independently of their timers. This simplifies debugging.
- Each job can be configured to run in a specific environment (see systemd.exec(5)).
- Jobs can be attached to cgroups.
- Jobs can be set up to depend on other systemd units.
- Jobs are logged in the systemd journal for easy debugging.
- Jobs can be easily started independently of their timers. This simplifies debugging.
- Each job can be configured to run in a specific environment (see systemd.exec(5)).
- Jobs can be attached to cgroups.
- Jobs can be set up to depend on other systemd units.
- Jobs are logged in the systemd journal for easy debugging.
Caveats
Caveats
Some things that are easy to do with cron are difficult to do with timer units alone.
Some things that are easy to do with cron are difficult to do with timer units alone.
- Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
- Emails: there is no built-in equivalent to cron's MAILTO for sending emails on job failure. See the next section for an example of setting up an equivalent using OnFailure=.
- Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
- Emails: there is no built-in equivalent to cron's MAILTO for sending emails on job failure. See the next section for an example of setting up an equivalent using OnFailure=.
