Cron vs systemd timers

cronsystemd-timer

It was recently pointed out to me that an alternative to cron exists, namely systemd timers.

However, I know nothing about systemd or systemd timers. I have only used cron.

There is a little discussion in the Arch Wiki. However, I'm looking for a detailed comparison between cron and systemd timers, focusing on pros and cons. I use Debian, but I would like a general comparison for all systems for which these two alternatives are available. This set may include only Linux distributions.

Here is what I know.

Cron is very old, going back to the late 1970s. The original author of cron is Ken Thompson, the creator of Unix. Vixie cron, of which the crons in modern Linux distributions are direct descendants, dates from 1987.

Systemd is much newer, and somewhat controversial. Wikipedia tells me its initial release was 30 March 2010.

So, my current list of advantages of cron over systemd timers is:

  1. Cron is guaranteed to be in any Unix-like system, in the sense of being an installable supported piece of software. That is not going
    to change. In contrast, systemd may or may not remain in Linux
    distributions in the future. It is mainly an init system, and may be
    replaced by a different init system.

  2. Cron is simple to use. Definitely simpler than systemd timers.

The corresponding list of advantages of systemd timers over cron is:

  1. Systemd timers may be more flexible and capable. But I'd like
    examples of that.

So, to summarise, here are some things it would be good to see in an answer:

  1. A detailed comparison of cron vs systemd timers, including pros and
    cons of using each.
  2. Examples of things one can do that the other cannot.
  3. At least one side-by-side comparison of a cron script vs a systemd
    timers script.

Best Answer

Here are some points about those two:

  1. 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 much easier.

  2. systemd timers are systemd services with all their capabilities for resource management, IO CPU scheduling, ...
    There is a list :

    • systemcall filters
    • user/group ids
    • membershipcontrols
    • nice value
    • OOM score
    • IO scheduling class and priority
    • CPU scheduling policy CPU
    • affinity umask
    • timer slacks
    • secure bits
    • network access and ,...
  3. with the dependencies option just like other systemd services there can be dependencies on activation time.

  4. 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 ,...

  5. much easier configuration some files and straight forward tags to do variety of customizations based on your needs with systemd timers.

  6. Easily enable/disable the whole thing with:

    systemctl enable/disable 
    

    and kill all the job's children with:

    systemctl start/stop
    
  7. systemd timers can be scheduled with calenders and monotonic times, which can be really useful in case of different timezones and ,...

  8. systemd time events (calendar) are more accurate than cron (seems 1s precision)

  9. systemd time events are more meaningful, for those recurring ones or even those that should occur once, here is an example from the document:

    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 
    
  10. From the CPU usage view point systemd timer wakes the CPU on the elapsed time but cron does that more often.

  11. Timer events can be scheduled based on finish times of executions some delays can be set between executions.

  12. The communication with other programs is also notable sometimes it's needed for some other programs to know timers and the state of their tasks.

Related Question