As a Linux user you’re probably familiar with cron. It has worked as the go-to Unix time-based job scheduler for many years. Now many users are seeing Systemd timers begin to replace cron’s dominance.
This article will discuss the basics of how to set up your own timer and make sure it’s running properly on your system.
If you’re already using Systemd as an init system – many popular Linux distros run it by default, including Arch, Debian, Fedora, Red Hat, and Ubuntu – you will see timers already in use. There’s nothing left to do other than use that feature already installed.
List Existing Timers
The easiest way you can check that a timer exists on your computer is with the command:
You don’t have to run this as root.
--all option here shows inactive timers as well. There aren’t any inactive timers currently on this system.
You should find an output similar to the following image:
You can see the date and time each timer will activate, the countdown until that point, how much time has passed since it last ran, the unit name of the timer itself, and the service each timer unit activates.
All timers must be paired with a corresponding service. In the next section you will see how to create a “.timer” file that activates a “.service” file.
Creating a New Timer
You can create a new timer by placing a custom .timer file in “/etc/systemd/system/.” In creating a new timer for my DuckDNS dynamic DNS service file, I ended up with this text:
1. [Unit] section
The “Description=…” option in the file tells you the name/description of the timer itself. In this case my “duckdns.timer” will update my DNS by telling the “duckdns.service” file to run a series of commands.
You can change the wording after “Description=” to say whatever you like.
2. [Timer] section
“OnCalendar=…” here shows one way of telling the timer when to activate.
*-*-* stands for “Year-Month-Day, and the asterisks mean it will run every day of every month of every year from hereon forward. The time that follows the asterisks shows what time of the day the timer should run.
“Persistent=true” just means that the timer will run automatically if it missed the previous start time. This could happen because the computer was turned off before the event could take place. This is optional but recommended.
3. [Install] section
Finally, “WantedBy=timers.target” shows that the Systemd timers.target will use this .timer file. This line in the file shows the dependency chain from one file to another. You should not omit or change this line.
You can find many other features by scanning Systemd’s man page with
man systemd.timer. Navigate to the “OPTIONS” section to discover options for accuracy, persistence, and running after boot.
Running the Timer
Activate any timer you’ve created with the
systemctl enable and
systemctl start syntax.
Look again at
systemctl list-timers to see your timer in action.
You can see if your timer ran as expected by inspecting its corresponding service file with
systemctl status. In this case you can see that my timer ran at 11:43:00 like it was supposed to.
Although many third-party programs, including DuckDNS, come with scripts that allow them to update as needed, creating timers in Systemd is a helpful skill to know. My creation of a timer for DuckDNS here was unnecessary, but it shows how other types of Systemd timers would work.
This knowledge will be helpful, for instance, for creating and running your own Bash scripts. You could even use it to alter an existing timer to better suit your preferences. Furthermore, it’s always good to know how your computer operates, and since Systemd controls many basic functions, this one piece of the puzzle can help you better understand the manner in which events are triggered every day.
Thanks for following along. Good luck with creating your own timers.