WIUNIX ACADEMY

Reliable systemd timers: missed runs, repeatable jobs and completion intervals

Page 4 of 4. Review the earlier steps and prerequisites before continuing.

YOUR SYSTEM. YOUR STEPS.

Where are you working?

Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.

Ubuntu 26.10Reviewed against official documentation · 2026-11-05

USE YOUR OWN VALUES

Configure this tutorial

Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.

Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.

Set values for my environment3 editable values

LET’S BUILD

Validate and load the interval alternative

Run the verifier again for the changed fixture, reload the manager, and start the timer. Expect a possible immediate boot-relative activation on an already running host. Inspect the next monotonic occurrence and journal instead of expecting the UTC daily schedule to remain.

Do not combine the two designs casually: multiple trigger settings are alternatives that can each fire, rather than conditions that must all be true. Replacing the entire file here avoids accidentally keeping both.

Terminal on the authorized staging host

sudo systemd-analyze verify '/etc/systemd/system/academy-daily-marker.service' '/etc/systemd/system/academy-daily-marker.timer' || exit 1
sudo systemctl daemon-reload || exit 1
sudo systemctl enable --now 'academy-daily-marker.timer' || exit 1
systemctl is-enabled --quiet 'academy-daily-marker.timer' || exit 1
systemctl is-active --quiet 'academy-daily-marker.timer' || exit 1
systemctl list-timers --all 'academy-daily-marker.timer'
systemctl show 'academy-daily-marker.timer' -p ActiveState -p SubState -p NextElapseUSecMonotonic

How do I know it worked?

The timer uses the completion-relative file and its next occurrence is consistent with the service lifecycle.

LET’S BUILD

Restore the saved calendar schedule or leave the fixture disabled

If the optional interval was used, stop the timer and this harmless fixture service, restore only the saved calendar file, then validate and reload it. This interrupts only the marker job; use an application-specific stop procedure for real work. Persistent history is retained, so catch-up may follow activation.

To retire the fixture instead, leave its timer disabled using the earlier pause panel and retain the named files, state and journal until reviewed. Do not remove application data or broad state directories as part of scheduler troubleshooting. If you later uninstall the timer deliberately, use systemd’s documented state-cleanup procedure for that exact timer.

Terminal on the authorized staging host

sudo systemctl disable --now 'academy-daily-marker.timer' || exit 1
sudo systemctl stop 'academy-daily-marker.service' || exit 1
sudo test -f '/etc/systemd/system/academy-daily-marker.timer.calendar-backup' || exit 1
sudo cp -p -- '/etc/systemd/system/academy-daily-marker.timer.calendar-backup' '/etc/systemd/system/academy-daily-marker.timer' || exit 1
sudo systemd-analyze verify '/etc/systemd/system/academy-daily-marker.timer' || exit 1
sudo systemctl daemon-reload || exit 1
sudo systemctl enable --now 'academy-daily-marker.timer' || exit 1
systemctl is-enabled --quiet 'academy-daily-marker.timer' || exit 1
systemctl is-active --quiet 'academy-daily-marker.timer' || exit 1
systemctl list-timers --all 'academy-daily-marker.timer'

How do I know it worked?

The saved calendar schedule is restored and waiting, or the fixture is deliberately left disabled with its evidence retained.

Decide whether the real job is ready for a timer

Keep the job separate from its schedule: verify a manual success and repeat run, inspect a real scheduled activation, and record the installed systemd version, actual duration and application result. Test interruption and recovery only in a safe staging environment. This tutorial’s commands were reviewed against primary documentation; they were not executed across all listed distributions or on your host.

Before adapting it, decide what a missed run means, whether work can repeat, how partial commits recover, how long the job may run, and how failures will reach an operator. A machine-local timer plus a zero exit status cannot replace those application guarantees. For filesystem isolation after those decisions, continue with the separate systemd hardening guide.

GO TO THE SOURCE

Official references

Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.

KEEP LEARNING

Your next step

Explore all tutorials ↗