30. 12. 2022 Davide Gallo Contribution, NetEye, Service Management

Start Using systemd Timers instead of cron/anacron

systemd timers are a way to schedule tasks in Linux systems using the systemd initialization system. They provide finer granularity for scheduling tasks than the traditional crontab, and also ensure that the task will be executed when the system is running in the future, even if the expected execution time was missed due to the system being turned off.

What is a systemd Timer in Detail?

All users can use systemd timers, and they can be easily monitored using tools like Icinga. They consist of two configuration files:

A timer unit that defines the schedule
A service unit that defines the task(s) to be performed.

Why systemd Timers instead of cron/anacron?

There are several reasons why someone might choose to use systemd timers instead of cron:

Reliability: systemd timers ensure that the task will be executed when the system is running at later time, even if the expected execution time was missed due to the system being off. This is not the case with cron, which will not execute a missed task.
Availability: systemd timers are available to all users, while cron is typically only available to the root user.
Debugging and testing: systemd timers allow you to test and debug the execution of the task in the environment it will run in, which can be helpful when developing and maintaining scripts.
Ease of monitoring: As I mentioned earlier, systemd timers can be easily monitored using tools like Icinga, which can be useful for tracking and managing scheduled tasks.
Ease of reading: systemd timers provide a more intuitive and easy-to-read syntax for scheduling tasks compared to cron. While cron uses a somewhat cryptic syntax for defining the schedule of a task, systemd timers use a more human-readable format that is easier to understand and work with.

Overall, systemd timers provide a more flexible and reliable way to schedule tasks in Linux systems, and are a good alternative to cron for those who need more advanced scheduling capabilities, or easier monitoring options.

Examples

As already explained, we need two files in order to use systemd timers. We need the service unit and the timer unit.

Here’s an example of a systemd timer unit file that will execute a task every hour at the beginning of the hour:

[Unit]
Description=Execute task every hour

[Timer]
OnCalendar=hourly

Unit=mytask.service

[Install]
WantedBy=timers.target

This timer unit file specifies that the task should be executed every hour (using the OnCalendar=hourly directive) and that the task is defined in the mytask.service unit file (using the Unit=mytask.service directive).

Here is an example of a corresponding service unit file that defines the task to be performed:

[Unit]
Description=My task

[Service]
Type=simple
ExecStart=/path/to/task/script.sh

[Install]
WantedBy=multi-user.target

This service unit file specifies that the task is a simple command that is executed by running the script.sh script located at /path/to/task/.

To enable and start the timer and the task, you can use the following systemctl commands:

systemctl daemon-reload
systemctl enable mytask.timer
systemctl start mytask.timer

This will schedule the task to be executed every hour at the beginning of the hour. You can then use the systemctl status mytask.timer command to check the status of the timer and see when it’s scheduled to run next.

Tip: You can (and should) leave the service unit alone (neither enable nor start it). This is now handled by the timer unit.

Troubleshoot and Monitoring

If you see any errors or issues in the output of these commands, it may indicate a problem with the timer or the service. You can also use the journalctl command to view the system log and see if there are any messages related to the timer or the service.

To view a list of all systemd timers on your system, you can use the systemctl command with the --type=timer option. This will list all of the timer units that are available on your system, along with their current status and next scheduled execution time.

This will also show you their unit file name, load state, and active state. The load state indicates whether the timer unit file has been loaded by systemd, while the active state indicates whether the timer is currently running or waiting to run.

You can also use the --all option to include disabled timer units in the list, and the --failed option to show only timer units that have failed to start.

For example, to list all timer units, including disabled ones and failed ones, you can use the following command:

systemctl --type=timer --all --failed

To monitor systemd timers in Icinga, you can use the check_systemd module available on the Icinga Exchange. This module allows you to check the status and timestamps of systemd timer units and service units.

Resources

These Solutions are Engineered by Humans

Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles just like this and other roles here at Würth Phoenix.