systemd Timer Units
The third tool the scheduling objective names, and the one Red Hat now ships its own periodic work as. A timer is two units - a .service that does the work and a .timer that says when - and unlike cron the schedule can be checked with a command before you rely on it.
Deploy and Maintain Guide 45 of 67 Intermediate
- OSRHEL 10.0
- Kernel6.12.0-55.9.1.el10_0
- dnf4.20.0
- Flatpak1.16.0
- TimeAbout 13 min
A .timer and its .service share a name: foo.timer activates foo.service unless Unit= says otherwise. Enable the timer, not the service - enabling the service would run it at boot, which is not what a schedule means.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| RHCSA-A01 | 192.168.0.31 | RHEL 10.0 | Practice node (graded) - spare /dev/sda | 2 Core | 4 GB | 50 GB + 15 GB |
This guide includes
Use this for the third scheduling tool, and the one Red Hat now ships by preference. This matters because a timer is two units rather than one - and the schedule can be checked before you trust it.
- writing the two units a timer actually needs
- checking the schedule before trusting it
- deciding between cron and a timer
Before you start
- A sudo-capable account.
- The session writes two unit files and removes them.
-
The two units
-
Checking the schedule before trusting it
-
cron or a timer