Timers — systemd's Replacement for Cron

systemd1-3's own Type=oneshot material previewed exactly this chapter. Timers are systemd's own scheduled-task mechanism — genuinely different from cron, not just a reskinned version of it.

The Two-Unit Pattern — .timer + .service

A systemd timer is genuinely two separate unit files working together: a .timer unit defining when to run, and a .service unit defining what to run — by convention, sharing the same base name (backup.timer + backup.service). A deliberate design decision distinct from cron: the "what" is a real, independently-runnable systemd service — exactly systemd1-3's own Type=oneshot material — cleanly separated from the "when." You can run and test the service directly at any time with systemctl start backup.service, with no need to wait for or fake the timer at all.

OnCalendar= — Scheduling Syntax

The general shape: DayOfWeek Year-Month-Day Hour:Minute:Second, with wildcards (*) and shorthand keywords (daily/weekly/monthly/hourly) covering common cases without needing the full explicit syntax.

Verifies a calendar expression means what you think it means before deploying it, printing the next several actual trigger times — genuinely worth running on any expression before trusting it.

A Full Worked Timer Example

Notice: you enable and start the timer, not the service directly — the timer itself then triggers the service at the scheduled time. WantedBy=timers.target is systemd1-5's own target material made concrete for a specific new case — a dedicated target that exists purely to group active timers.

Persistent=true — Catching Up Missed Runs

The real, standout advantage over cron. Persistent=true tells systemd to check, at boot, whether this timer's scheduled trigger was missed while the system was off — a laptop shut down overnight through the scheduled 3am backup, for instance — and if so, run it once, immediately, upon boot, rather than silently skipping that day entirely. Traditional cron has no native equivalent: a missed cron job, with the system off at the scheduled time, is simply missed, silently, until the next scheduled occurrence.

Direct Comparison Against Traditional Cron

Real, concrete advantages: dependency-awareness (a timer's own service can Wants=/After= other units — waiting for a network mount before running a backup, genuinely impossible to express cleanly in a crontab); automatic journald logging (systemd1-6's own material — every timer-triggered run is automatically logged and queryable via journalctl -u backup.service, unlike cron's own historical reliance on separate mail-based or ad-hoc logging); Persistent=true's own missed-run catch-up; and direct testability, per this chapter's own opening point. An honest note: cron's own crontab syntax is genuinely more compact for the simplest cases, and cron remains extremely widely deployed and understood — this isn't a "cron is bad" chapter, just an honest accounting of what systemd timers genuinely add.

Hands-On Exercises