Stop Fighting Cron: Practical systemd.timer Units on Linux
A practical guide to using systemd.timer units on Linux as a modern replacement for cron, covering calendar and monotonic timer configurations.
Stock photo for illustration only, not from the actual event
- systemd.timer replaces traditional cron with better logging and dependency ordering
- Supports both wall-clock calendar expressions and monotonic time spans
- Includes built-in controls for random delays and execution overlap prevention
Many administrators still rely on traditional crontab files, but systemd provides a first-class alternative: .timer units. A timer unit manages when a job runs, while a matching service unit defines what action to take. This approach gives you the same logging, sandboxing, credentials, and resource controls already used for standard system daemons, alongside calendar expressions that are much easier to test than standard five-field cron strings.
This operational guide is based on systemd.timer(5), systemd.time(7), systemd.service(5), systemd.exec(5), systemctl(1), and stock units on systemd 257, verified on Debian 13 and version 257.13. It can successfully replace most recurring tasks that run every night, every few minutes, or once after system boot, offering improved observability and dependency management.
Stock photo for illustration only, not from the actual event
When examining timer types, Realtime timers use the OnCalendar= directive to follow the system wall clock and timezone. If the machine goes to sleep while a calendar event elapses, systemd catches up upon resume, triggering the service once even if the expression matched multiple times during sleep.
Moving from cron to systemd.timer solves long-standing frustrations regarding error logging, environment variables, and job sequencing. Integrating scheduled tasks directly into the systemd ecosystem ensures robust lifecycle management for all automated server tasks.
Always validate your expressions before deployment using tools like systemd-analyze calendar. On systems lacking a battery-backed RTC, enabling systemd-time-wait-sync.service ensures that calendar-based timers wait until network time synchronization is established.
Understanding configuration knobs such as AccuracySec= and RandomizedDelaySec= is crucial. While they sound similar, they perform distinct tasks: AccuracySec= defines scheduling precision, while RandomizedDelaySec= introduces random jitter to spread out execution loads across large fleets, as seen in stock configurations like fstrim.timer.
Setting Persistent=true on calendar timers instructs systemd to store the last trigger timestamp on disk. If the host is powered off during a scheduled execution window, the service will run once immediately upon the next timer activation, subject to any configured random delay parameters.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment