Comparing Cron Jobs and SystemD Timers

Content:

The traditional method of automating tasks is to use a cron daemon, and set up a cron job. cron was first introduced in 1975, and several

Cron jobs are very simple – the installed cron application will run the command entered into the crontab, at the frequency specified. It’s possible to run pretty much anything this way – if you can run it manually in a terminal, you can run it as a cron job.

SystemD is a modern init system, used by most Linux distributions. SystemD introduces its own way to run scheduled tasks, known as SystemD timers.

SystemD timers are more complex, requiring a service to be created to run the task. SystemD services are an integral part of a system using SystemD, with the entire init system constructed of such services.

Here are a few differences between the two.

Testing

To test a cron job, the command can be ran directly in a terminal. It’s important to run the command as the same user as the cron job, to ensure pathing and permissions are the same.

SystemD services can be easily controlled using systemctl. For example, the following command can be used to start the service with the specified service name.

systemctl start servicename

This makes it easy to run the scheduled task at any time, while still running the exact same task the SystemD timer will run.

Logging

When using cron, it’s important to consider any logging requirements when setting up the job. Logging must form part of the script being run by the cron command, as cron itself has no logging capability.

Output from a job ran using a SystemD timer is logged automatically, and appears in the system journal. You can fetch the log for a specific service using the command

journalctl -u servicename.service

Reporting

One of the most useful features of cron is the ability to send an email to a specific address if the job fails. This functionality is available out of the box, and only requires a MAILTO address to be added to the top of the crontab.

MAILTO=email@domain.com

Without this, an email will be sent to the local user who the crontab belongs to.

This is somewhat more tricky using SystemD. To achieve similar functionality requires setting up a new SystemD service specifically to send error emails, and use service name as the OnFailure response for your the service you want to receive emails from.

Dependencies

This is an area where cron falters, with no easy way to manage dependencies in a script. It is up to the script to check that everything it requires is available at runtime.

SystemD services allow dependencies to be listed, ensuring the required services are started when the service is called.

This feature also allows for more complex interactions between services.

Conclusion

This has been a very basic overview of cron and SystemD timers. If your system is running SystemD, using the built-in timer mechanism can be a great way to run your scripts. The integrated logging and dependency systems are incredibly useful, removing the hassle of having to set these up yourself in your script.

That said, cron remains a useful option. Having been in use for decades, it’s very well documented. It’s compatible with any system running a cron daemon, and does not require a specific init system to run. Only requiring a single line in your crontab, it’s much easier to set up a cron job. For simple tasks, cron is still a great choice.

For more information on how to set up a cron job, check out our article.