A systemd timer schedules tasks on Linux systems. Each timer requires a matching service file that defines the command to execute. Timer units end with .timer and service units end with .service.
Timers integrate with the systemd journal for centralized logging and support dependency management between services.
Types of Systemd Timers
Systemd provides two timer categories.
Monotonic Timers
Monotonic timers activate after a duration relative to a reference point. These timers pause during system suspension.
| Keyword | Trigger Point |
|---|---|
OnBootSec |
Relative to machine startup |
OnActiveSec |
Relative to timer activation |
OnUnitActiveSec |
Relative to last service completion |
OnUnitInactiveSec |
Relative to last service stop |
Realtime Timers
Realtime timers trigger at specific calendar moments. Use the OnCalendar directive to define these timers.
| Expression | Meaning |
|---|---|
hourly |
Start of each hour |
daily |
Every day at midnight |
weekly |
Every Monday at midnight |
Mon..Fri 22:30 |
Weekdays at 10:30 PM |
Create a Service File
Create a service file in /etc/systemd/system/. Example service file named backup.service:
[Unit]
Description=Run backup script
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
The Type=oneshot parameter indicates the service completes a task then exits.
[Install] section.
Create a Timer File
Timer files define when the service runs. Create a timer file with the same base name as the service.
Monotonic Timer Example
Create backup.timer to run fifteen minutes after boot and repeat weekly:
[Unit]
Description=Backup timer
[Timer]
OnBootSec=15min
OnUnitActiveSec=1w
[Install]
WantedBy=timers.target
Realtime Timer Example
Create a calendar-based timer that runs every Monday:
[Unit]
Description=Weekly backup timer
[Timer]
OnCalendar=weekly
Persistent=true
[Install]
WantedBy=timers.target
The Persistent=true option ensures missed executions run after system restart.
Activate the Timer
Place both files in /etc/systemd/system/. Enable and start the timer:
$ sudo systemctl daemon-reload
$ sudo systemctl enable backup.timer
$ sudo systemctl start backup.timer
systemctl enable --now backup.timer.
View Running Timers
Display all active timers:
$ systemctl list-timers
Include inactive timers:
$ systemctl list-timers --all
Check a specific timer:
$ systemctl status backup.timer
OnCalendar Syntax
The OnCalendar directive accepts flexible time specifications. Validate calendar expressions:
$ systemd-analyze calendar "Mon..Fri 08:00"
Complex schedule examples:
OnCalendar=Mon,Wed,Fri 10:00
OnCalendar=*-*-* 06,12,18:00:00
OnCalendar=Sat *-*-1..7 15:00:00
Useful Timer Options
Persistent
Add Persistent=true to run missed executions after system downtime. The timer triggers immediately when the system restarts.
AccuracySec
Control execution precision with AccuracySec. Default is one minute. Set AccuracySec=1us for microsecond accuracy:
[Timer]
OnCalendar=daily
AccuracySec=1us
RandomizedDelaySec
Prevent simultaneous timer execution with random delays:
[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
The timer executes at a random time within one hour of the scheduled time.
Transient Timers
Create temporary timers without unit files using systemd-run. Run a command after thirty seconds:
# systemd-run --on-active=30 /bin/touch /tmp/testfile
Create a calendar-based transient timer:
# systemd-run --on-calendar="Mon 14:00" /usr/bin/cleanup.sh
Stop a running transient timer:
$ systemctl stop run-unit-id .timer
Advantages Over Cron
Systemd timers provide several benefits:
- Jobs log directly to the systemd journal
- Services can depend on other systemd units
- Resource control through cgroups
- Better error handling and failure notifications
- Missed jobs run automatically with
Persistent=true
View logs with journalctl -u service-name.
FAQs
Systemd timers integrate with the journal for centralized logging. They support dependencies between services and provide resource control. Cron requires manual logging configuration and lacks service dependency management.
No. Each timer file triggers one service. Create separate timer units for each service. Use the Unit= directive to specify a differently-named service if needed.
Set Persistent=true in the timer configuration. The timer triggers immediately when the system restarts if it missed one or more scheduled executions during downtime.
Manually trigger the associated service with systemctl start service-name.service. This executes the service immediately without affecting the timer schedule. Check logs with journalctl.
Place custom timer and service files in /etc/systemd/system/. System-provided units reside in /usr/lib/systemd/system/. User-specific timers go in ~/.config/systemd/user/.