Here are some points about those two:
checking what your cron job really does can be kind of a mess, but
all systemd timer events are carefully logged in systemd journal
like the other systemd units based on the event that makes things
systemd timers are systemd services with all their capabilities for resource management, IO CPU scheduling, …
There is a list :
- systemcall filters
- user/group ids
- nice value
- OOM score
- IO scheduling class and priority
- CPU scheduling policy CPU
- affinity umask
- timer slacks
- secure bits
- network access and ,…
with the dependencies option just like other systemd services
there can be dependencies on activation time.
Units can be activated in different ways, also combination of
them can be configured. services can be started and triggered by
different events like user, boot, hardware state changes or for
example 5mins after some hardware plugged and ,…
much easier configuration some files and straight forward tags to
do variety of customizations based on your needs with systemd
Easily enable/disable the whole thing with:
and kill all the job’s children with:
systemd timers can be scheduled with calenders and monotonic
times, which can be really useful in case of different timezones and
systemd time events (calendar) are more accurate than cron (seems
systemd time events are more meaningful, for those recurring ones
or even those that should occur once, here is an example from the
Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00 Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00 Wed *-1 → Wed *-*-01 00:00:00 Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00 Wed, 17:48 → Wed *-*-* 17:48:00
From the CPU usage view point systemd timer wakes the CPU on the
elapsed time but cron does that more often.
Timer events can be scheduled based on finish times of
executions some delays can be set between executions.
The communication with other programs is also notable sometimes
it’s needed for some other programs to know timers and the state of
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:
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.
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=.