Some Linux distributions no longer ship cron.
Its time to check out systemd timers.
Its dependability soon made it a favorite tool for scheduling tasks to run at specified dates and times.
Admittedly, its syntax is pretty quirky.
In cron schedules, days and months are numbered starting at one.
And on some systems, seven means Sunday, too.
But, as quirky as this might be, it works.
The systemd service manager brought much more to the table than a simple replacement for the init boot manager.
Part of what it delivered was a modern replacement for cron, in the form of systemd timers.
Hannah Stryker / How-To Geek
These offer more flexibility than cron does, and without the need for another external utility.
Theyre built right into all systemd distributions.
That means timers behave the same way on all systemd installations.
There are many versions of cron and cron-like substitutes.
If you gotta have standardization across a number of computers, systemd makes your life easier.
The same timers will spin up the same way on all of them.
In fact, some systemd-based distributions no longer ship cron as part of their standard offering.
Not surprisingly, the Red Hat-derived distributions includingFedoradont ship cron, because systemd is aRed Hatinitiative.
Other distributions, such as Solus, don’t see a need to include cron either.
When the service runs, it launches your process for you.
So the service file needs to know about your target process.
The second file it’s crucial that you create is atimerfile.
This determines when the service is launched.
So the timer file needs to know about your service file.
Real-time timers are triggered by calendar events.
Monotonic timers are triggered at some duration after a system event, such as booting.
Log entries are added to the system journal for timer events, which can help with debugging.
you might list the timers on your setup by using the status option of the systemctl command.
Thatll tell us our service is working, and when it was last triggered.
Well create the script in the /usr/local/bin/ directory.
Were using the gedit editor, but you’re free to use whichever editor you prefer.
Copy these lines into your editor, save the file as geek-timer.sh, and close your editor.
Well need to make our script executable.
Lets just check that our script does what it is meant to.
That verifies that our script executes as expected and puts a timestamp into the timer.log file.
Copy these lines to your editor, save the file as /etc/systemd/system/geek-timer.service, and close your editor.
The [Unit] section contains two lines.
The “Description=” line is a simple one-liner that says what your service is for.
The Requires= line indicates that this service relies on the geek-timer.timer timer file.
Well create this file next.
Theres a little bit more in the [Service] section.
The jot down= is “simple”, meaning this is a basic service.
Other options include oneshot, which would mean the service ran once only.
The ExecStart= line indicates which process the service should start.
This is pointing to our script that we created earlier.
The User= line defines which user should trigger the command.
Without this, the process would be launched by root.
Now well create the timer file.
This defines when the service is launched.
Its good practice to use the same base name for the server and timer files, with different extensions.
Copy these lines to your editor, save the file as /etc/systemd/system/geek-timer.timer, and close your editor.
The [Unit] section contains a Description= line of text.
The [Timer] section contains three prefs.
The Unit= line indicates which service should be launched when this timer triggers.
The OnBootSec= line tells the system to launch the service five minutes after the computer boots.
The OnUnitActiveSec= line tells the timer to launch the service one minute after it last activated.
In other words, five minutes after the computer is booted, the service will launch.
The service will then repeat with an interval of one minute.
We can use the systemctl status command to look at our new timer.
There are no errors reported, which is good.
It is inactive because we havent started the service.
Even if we reboot now, our service and timer wont be enabled.
Lets start and enable our timer.
This shows the PC booted at 12:18, and our timer is going to be triggered at 12:23.
Our requested five minutes after boot option is being handled correctly.
I waited for the five minutes to expire and then quickly ran the same command.
We can see that the trigger time has moved on one minute from 12:23 to 12:24.
This means were now into the “repeating every minute phase” of our timer.
That’s why I said the events in the logfile areaboutone minute apart.
Usually, for tasks like starting a backup or other system housekeeping activities, thats accurate enough.
If you oughta have a tighter resolution, you’re free to use microsecond timing.
These are the accuracy tweaks you might use, and how you might refer to them.
To have a timer trigger at a particular time and date is achieved using the OnCalendar setting.
This goes in the [Timer] section of the timer file.
The general format is:
DayOfTheWeek is optional.
Ranges of values are indicated by using two periods .. to separate the start and values of a range.
This would set a timer to trigger at 01:15 on the first Friday of each month.
This would run a process at 19:00 every day.
A timer can have more than one trigger time set.
This would run a process at a different time on business days than on the weekend.
Thesystemd time man pagefull description of time formats and many useful tips and tricks.
The last 10 percent is embracing the graceful power of calendar events.
Related:How to Run a Linux Program at Startup With systemd
