In this lesson, you will learn how to replace traditional cron jobs with systemd timers to gain precise, observable control over your background task scheduling.
Why move beyond cron?
While cron is the classic tool for scheduling, it functions as an external process. By moving your tasks into systemd, you integrate your scheduled jobs into the system’s service manager. This allows you to leverage features you’ve already mastered, such as dependency tracking, logging with journalctl, and sophisticated resource sandboxing.
The Two-Unit Pattern
A systemd timer does not run a command directly. Instead, it works as a pair:
- The Service Unit (
.service): Defines what to run (the script or binary). - The Timer Unit (
.timer): Defines when to run the service.
For example, if you have a backup script, you first create backup.service to define how it executes. Then, you create backup.timer:
[Unit]
Description=Run daily backup
[Timer]
# Execute every day at midnight
OnCalendar=daily
# Ensure it runs if the system was off at the scheduled time
Persistent=true
[Install]
WantedBy=timers.target
Why this matters
Because the timer triggers a systemd service, you can use systemctl status backup.service to see exactly when it last ran, if it succeeded, or if it failed. You can also define "ordering dependencies" so that your backup only runs after a specific mount point is ready.
Unlike cron, which often hides errors in local mail spools, systemd timers stream all output directly into the journal. By using OnCalendar syntax, you can specify complex schedules—like "Mon..Fri --* 03:00:00"—with human-readable clarity that makes managing background orchestration significantly more reliable and observable than legacy crontabs.
To activate your timer, you simply enable and start it just like any other unit: systemctl enable --now backup.timer. You can list all active timers on your system at any time by running systemctl list-timers.
Key Takeaway: Systemd timers turn background tasks into managed units, providing integrated error logging, dependency awareness, and lifecycle control that legacy cron jobs cannot match.