Systemd Timers - a better alternative for crontab?

Cron is the ubiquitous job scheduler in the Linux world. Anyone who wants to run a periodic automation or a one-off script at a predetermined time interval has used cron. Plenty of housekeeping tasks run as scheduled jobs by default on all Linux systems. The files under /etc/cron.* will give you an idea on these cron jobs.

For a very long time crontab has been the undisputed choice for scheduling jobs on Linux systems. But with the wide adoption of systemd as the system and service manager, it has given us a new option - systemd timers.

Most casual Linux users consider systemd as a modern replacement for the SysV init system. While it is partially true, systemd is much more than that. To quote the systemd website:

systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic.

While a discussion on the systemd capabilities is outside the scope of this article, the following points will serve as a refresher to better understand this article:

• Systemd owns PID1 and is started by the Linux kernel

• All other processes in the system are descendants of systemd

• It is responsible for filesystem initialization

• The fundamental building block of the systemd ecosystem is the concept of units

• A unit is a system resource that systemd knows how to manage

• There are different types of units, including services, devices, mountpoints, sockets, etc

• The definition and configuration of a unit is stored in unit files under different directories managed by systemd

• There are system level units and user level units

With that background set, let's get back to running crons with systemd timers.

Systemd Timers

Systemd provides an alternative to crons in the form of systemd timers. Timers are a type of unit files that define how a job or a service can be run on calendar events or monotonic events. Calendar events are similar to cron time and date fields, set based on a calendar time, and can be recurring as well. Monotonic events are configured as a time delta from the occurrence of an event, say boot time.

• A systemd timer unit file will have the extension .timer

• For every systemd timer unit file, there will be another unit file with the same name and a .service extension

• The timer unit defines the “when to run”, whereas the service unit defines the “what to run”

Let's use an example to demonstrate how timers work.

Consider the scenario of taking a MySQL backup every three hours. A crontab entry would look like this:

0 */3 * * *  /usr/local/bin/mysql-backup.sh

And the script would be

cat /usr/local/bin/mysql-backup.sh

#!/bin/bash
/usr/bin/mysqldump inventory  > /opt/db-backup/inventory-db-backup_`date +%H-%d-%m-%Y`.sql

The authentication will be taken care of with /root/.my.cnf

[client]
host=localhost
user=MYSQL_BACKUP_USER
password=MYSQL_BACKUP_PASSWORD

Now let us see how to move this cron to a systemd timer.

First we need to translate our backup script into a systemd service.

cat /etc/systemd/system/mysql-backup.service

[Unit]
Description="MySQL Backup Service"
[Service]
ExecStart=/usr/local/bin/mysql-backup.sh

Now we need to create the timer unit

cat /etc/systemd/system/mysql-backup.timer
[Unit]
Description="Run mysql-backup.service every 3 hours"

[Timer]
OnCalendar=*-*-* 00/3:00:00
Unit=mysql-backup.service

[Install]
WantedBy=multi-user.target

Most parts of these unit files are self-explanatory and are not different from normal unit files. The timer section describes what service to run ( mysql-backup.service ) and one or more time options. In this particular case, we are giving a specific calendar timing that executes the service once every three hours. We will look at a few more timer options later.

Now, verify the files are syntactically correct.

sudo systemd-analyze verify /etc/systemd/system/mysql-backup.*

If this command doesn't return any output, then we are good to proceed.

Reload systemd to update the system about new unit files.

sudo systemctl daemon-reload

Enable and start the timer unit.

sudo systemctl enable --now mysql-backup.timer

The timer is active now.

sudo systemctl status mysql-backup.timer
● mysql-backup.timer - "Run mysql-backup.service every 3 hours
     Loaded: loaded (/etc/systemd/system/mysql-backup.timer; disabled; vendor preset: enabled)
     Active: active (waiting) since Sat 2023-03-08 21:07:23 IST; 3s ago
    Trigger: Sun 2023-03-09 00:00:00 IST; 2h 52min left
   Triggers: ● mysql-backup.service

As you can see, the timer is enabled and the next run time is also listed.

Now let us look at the few ways the timers can be configured. As mentioned in the beginning, there are two categories of timers - real time ( calendar based ) and monotonic ( based on events ).

Monotonic timers

Monotonic timers are triggered after a specific time elapsed from an event, like boot time. There are different options to configure the monotonic timers, some of them are given below.

• OnBootSec: time after the machine boots up

• OnActiveSec: time after the timer unit is activated

• OnUnitActiveSec: time after the service unit was last activated

• OnUnitInactiveSec: time after the service unit was last deactivated

• OnStartupSec: time after the service manager is started

There are various formats in which you can provide values to the monotonic timer options. Some of them are

• 5hours

• 34minutes

• 5hours 34minutes

• 1y 3month

Real-time timer

Triggered by calendar events, the real-time timers have only one option: “OnCalendar”. This is the option that closely resembles crontab timers, so let's have a quick comparison.

Crontab Format:   minute hours day-of-the-month month day-of-the-week

This is a five-part format that can use *, absolute values, ranges, and lists for each part.

Systemd Timer Format:  Day Of the week      Year-Month-Date      Hour:Minute:Second

This three-part format works as follows:

• First part is the day of the week with 3 character values from Mon to Sun

• Second part is Year-Month-Date in number format with 4 digit years, two digit month and day

• Third part is time - 2 digits per hour, minute, and second

• A continuous range of values can be indicated with two dots. Eg: Mon..Wed mean Mon, Tue, Wed

• A list of values can be indicated with a comma. Eg: Sat,Sun

• Asterisk can be used as a wild card to match all valid values. Eg: “*” in the first part means all weekdays - Mon..Sun

• “/” can be used as a repetition option

• Default values can be skipped and the syntax can be shortened in specific ways

• Shorthands like minutely, hourly, yearly, etc can be used as a timer

The systemd time manpage covers the time formats in detail. Refer - https://man.archlinux.org/man/systemd.time.7

A few values for OnCalendar option are:

• Sat,Sun --* 23:00 - Every Saturday and Sunday at 11

• 2023-02-14 00:00:01 - 1 second into 14 Feb 2023

• --* 00/3:00:00 - Every three hours

• 23:40/5 - Every day every 5 minutes starting 11:40 PM

The variety of values in the OnCalendar option can be confusing. To ensure we provide the right values, systemd provides a command-line option. Let us validate the last value from this list as follows:

sudo systemd-analyze calendar --iterations=2 "23:40/5"
  Original form: 23:40/5
Normalized form: *-*-* 23:40/5:00
    Next elapse: Sat 2023-03-08 23:40:00 IST
       (in UTC): Sat 2023-03-08 18:10:00 UTC
       From now: 17min left
       Iter. #2: Sat 2023-03-08 23:45:00 IST
       (in UTC): Sat 2023-03-08 18:15:00 UTC
       From now: 22min left

As you can see, the command interprets the shorthand and expands into the normalized form, it also provides when the next few occurrences of the schedule will be ( controlled with –iterations ). It also tells you how much time from your current time will the event occur.

Conclusion

As you can see, the systemd timers are very versatile. Crontab provides the simple and efficient form of scheduling, and is available ubiquitously on all Linux operating systems, unlike systemd, which is not guaranteed to be available on all variants of Linux. Having said that, systemd is available on most popular operating systems and these are some of the advantages of timers.

• With service units, the jobs can be independently tested and run anytime without timers

• A job can be configured to depend on another systemd unit. For example, run the MySQL backup unit only if the mysqld service is running.

• Can be resource controlled with cgroups and slices

• Easy debugging with journalctl

• Time formats allow more control. Years and seconds are supported.

Do experiment with systemd timers. Most of the systemd options that can be used to customize the unit files can be used to better configure your timers and services. If you are running scheduled jobs for production systems, using the systemd timers makes more sense, and is easier to automate with configuration management tools.