systemd Timers

systemd Timers

systemd Timers, and When to Prefer Them

A timer is a unit that starts a service unit (systemd Services) on a schedule. You gain the journal for output, User= and sandboxing, no overlapping runs, Persistent=true to catch up after downtime, and RandomizedDelaySec= so a fleet does not fire at once. Ubuntu 225 already runs logrotate 1,548 , apt-daily and phpsessionclean from timers; /etc/cron.d/php exits when systemd 142,543 is running.

/etc/systemd/system/cache-prune.service and cache-prune.timerShell

[Service]
Type=oneshot
User=dev
ExecStart=/usr/bin/find /tmp/app-cache -type f -mtime +7 -print -delete
[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=15min
Persistent=true
[Install]
WantedBy=timers.target

Enabling the timer, then running its job once by handShell

sudo systemctl daemon-reload && sudo systemctl enable --now cache-prune.timer
systemctl list-timers cache-prune.timer
sudo systemctl start cache-prune.service; sudo journalctl -u cache-prune -o cat --since -1min

Output

NEXT                        LEFT LAST PASSED UNIT              ACTIVATES
Thu 2026-09-24 03:16:36 +08  13h -         - cache-prune.timer cache-prune.service
...
Starting cache-prune.service...
/tmp/app-cache/b.html
/tmp/app-cache/a.html
cache-prune.service: Deactivated successfully.
Finished cache-prune.service.

The random delay moved 03:15 to 03:16:36. systemd-analyze calendar 'Mon..Fri 03:15' tests an expression. Prefer timers for jobs that matter; keep cron for one-liners.

MENU