Timers vs Cron

## Two units, one job Cron packs a schedule and a command onto a single line. systemd deliberately separates them. A **timer unit** (`*.timer`) is a scheduling object with a `[Timer]` section and nothing executable in it. A **service unit** (`*.service`) is the thing that actually runs a command via `ExecStart=`. The timer's only job is to start the service at the right moment. This feels like extra ceremony until you see what it buys: the job is an ordinary unit, so everything systemd can do to a service — ordering, resource limits, environment, cgroup accounting, log capture — applies to a scheduled job for free, and you can run the job by hand with `systemctl start backup.service` in exactly the environment it will get on schedule. ```ini # /etc/systemd/system/backup.timer [Unit] Description=Nightly backup [Timer] OnCalendar=*-*-* 02:30:00 [Install] WantedBy=timers.target ``` ## How the timer finds its service The `[Timer]` section supports `Unit=`, naming the unit to activate. If you omit it, systemd uses the timer's own name with the suffix replaced by `.service`. So `backup.timer` → `backup.service`, `certbot-renew.timer` → `certbot-renew.service`. This default is why most timer units in the wild have no `Unit=` line at all. The corollary is a very common deployment bug: if you name the units differently — `backup.timer` next to `nightly-backup.service` — the timer elapses and tries to start a `backup.service` that does not exist. Either match the names or set `Unit=nightly-backup.service` explicitly. ## The paired service ```ini # /etc/systemd/system/backup.service [Unit] Description=Nightly backup job [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh ``` `Type=oneshot` tells systemd the process is expected to run to completion and exit; the unit is considered activated only once the command finishes, and it reports `inactive (dead)` in between runs. Seeing `inactive (dead)` on a scheduled job is normal. Seeing `failed` means the last run exited non-zero. Note that this service has no `[Install]` section on purpose. You are not going to enable it — the timer is what pulls it in. ## Enabling the timer, not the service This is the single most frequent cause of "my timer never fires": ```bash systemctl daemon-reload systemctl enable --now backup.timer systemctl list-timers backup.timer ``` `enable` makes the timer come up on the next boot; `--now` also starts it in this boot so you do not have to reboot to arm it. Enabling `backup.service` instead does something quite different — it asks for the job to run at boot — and leaves the schedule inactive. `systemctl daemon-reload` matters whenever you add or edit unit files: systemd works from an in-memory view of the unit database and will otherwise keep using the old (or absent) definition. ## Verifying it took `systemctl list-timers` prints one row per active timer with the next elapse, the time remaining, the last elapse, and — in the `ACTIVATES` column — the service each timer will start. That last column is the fastest way to confirm the pairing resolved to what you intended. `systemctl status backup.timer` shows a `Trigger:` line with the next firing time, and confirms the timer unit is `active (waiting)`. ## The failure modes, in order of how often you hit them 1. The **service** was enabled and the timer was not, so nothing is scheduled. 2. The timer was created but never started; it will only arm after a reboot, or not at all if it was never enabled. 3. `daemon-reload` was skipped after writing the files. 4. The names do not pair and no `Unit=` was given. 5. A syntax error in `[Timer]` makes the unit fail to load — `systemctl status backup.timer` reports the bad setting. All five are visible in under a minute from `systemctl list-timers` plus `systemctl status` on both halves of the pair.