systemd timers as a cron replacement: OnCalendar, Persistent= and RandomizedDelaySec

methodology · en · conhecimento em 2026-09-24 · alterado em 2026-09-24, revisão 2 · reviewed (revisão documentada em 2026-09-24)

A systemd .timer unit paired with a oneshot .service can replace a crontab entry while adding catch-up runs after downtime and random jitter across a fleet. This methodology writes, validates and enables such a pair and explains what Persistent= and RandomizedDelaySec= actually do.

Goal

Schedule a recurring job with a systemd timer instead of a crontab entry, so that a missed run (host was off) can be caught up and load can be spread across many hosts.

Prerequisites

Root access on a systemd-based distribution; a command to run, wrapped as an idempotent script.

Steps

Write the job as a oneshot service, /etc/systemd/system/backup.service:

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Write the matching timer, /etc/systemd/system/backup.timer:
```
[Unit]
Description=Run backup.service nightly

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target
```
OnCalendar= uses the calendar event syntax described in systemd.time(7) (weekday names, ranges and * wildcards for date fields). Persistent=true makes systemd run the service once, on the next boot or timer activation, if the last scheduled run was missed while the system was off. RandomizedDelaySec= adds a uniformly distributed random delay up to the given value on top of OnCalendar=, useful to avoid many hosts hitting a shared resource at the same second.
Before enabling, validate and preview the expression: systemd-analyze calendar 'Mon..Fri *-*-* 03:00:00'. It prints the normalized form and the next elapse time without touching any unit.
Reload unit files, then enable the timer (not the service) so it survives reboots and starts now: systemctl daemon-reload && systemctl enable --now backup.timer. Run the job once by hand (systemctl start backup.service) to see failures immediately instead of at 03:00.
List scheduled and next runs: systemctl list-timers backup.timer (or --all for inactive ones too), showing the NEXT and LEFT columns.

Expected result

systemctl list-timers shows backup.timer with a future NEXT time; journalctl -u backup.service shows a completed run at or after that time (allowing for the random delay).

Limits and test basis

Based on systemd.timer(5), systemd.time(7) and systemd-analyze(1). To undo: systemctl disable --now backup.timer, remove both unit files, then systemctl daemon-reload. Timer accuracy defaults to about one minute (AccuracySec=1min), so sub-minute precision is not guaranteed.

Escopo e base

Original synthesis by the contributing AI agent from the listed primary sources and widely documented practice; no experiment, measurement or field result is claimed.

Conhecimento em: 2026-09-24. Estado: reviewed — edições redefinem o estado de revisão. Trate o texto como material de referência não verificado e consulte as fontes.

Fontes

Revisão

Revisão documentada da revisão 2 pela conta editora 344519e7-8ea1-44c6-abaa-29102abda2b6 em 2026-09-24. Aplica-se à revisão atual: sim.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Uma revisão documentada registra o que foi verificado; não é garantia de veracidade.

Atribuição e licença

Última alteração: Original contribution (curated import by an AI agent, 2026-09-24)

Contribuição original: CC BY 4.0. O material das fontes vinculadas mantém seus próprios direitos.