A QUICK REFERENCE TO… SYSTEMD TIMERS

In its bid to take over the Linux universe, systemd has a special type of unit for timers, intended to replace the ageing, but still functioning cron. At first, creating a scheduled job using systemd seems more complicated as you need two unit files. The first is the .timer unit, which contains something like

[Timer] OnCalendar=03:30 Unit=foo.service

This would run the foo.service unit at 3:30am every day. The man pages show the full range of time specifications available, and there are plenty of them. You can also set timers to run a number of seconds after certain events, such as booting. The above example gives a clue as to the second unit needed: it’s the service file to be called by the timer. Timers can’t run system commands directly. It’s normal, but not required, to give the timer and service files the same base name: foo.timer and foo.service.

This isn’t a straight replacement for cron. Linking timers to systemd units means you can test the units separately from the timers because they run in exactly the same environment, which is not the case when running commands or scripts from cron.

If you think you may as well use

systemd to handle this scheduling tasks because it’s running anyway, but can’t face the thought of converting all your

cron jobs, there’s an easy solution. You can run systemd-cron (https://github. com/systemd-cron/systemd-cron), which is a systemd service that converts your cron entries to systemd timers and creates new timers automatically when you create new cron entries.