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.
All users can use systemd timers, and they can be easily monitored using tools like Icinga. They consist of two configuration files:
There are several reasons why someone might choose to use systemd timers instead of cron:
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.
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 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.
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.
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.