⌚ About 2 min read

Linux Intermediate. 15-30 min

This BAOI guide provides a structured method for diagnosing a systemd timer without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

1

Set perimeter

Identify the equipment, service, affected users and start time.
2

Collect Elements

Record the exact messages, logs and useful settings.
3

Test methodically

Start with the basic dependencies before the application components.
4

Apply correction

Change only the identified parameter or component.
5

Validate

Rewrite the full scenario and document the result.

Commands utiles

systemctllist-timers --all.

systemctl status name.timer

À retenir

Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.

Technical deep dive

systemd: state, journal, dependencies and timers

Technical checkpoints

systemctl status gives the latest state, while journalctl -u shows chronology and full service messages.
Restart= can create a loop that hides the first error; read the journal from boot or the initial timestamp.
For a timer, distinguish the .timer unit from the triggered .service unit and compare LAST/NEXT.

Service / timer

Read state, dependencies and journal before restarting.

systemctl status myservice
journalctl -u myservice --since today
systemctl list-timers --all

Topic-specific pitfalls

daemon-reload reloads unit definitions but does not automatically restart the service.
A successful timer can trigger a service that fails: inspect both units.

How to validate

The service remains active/running across several cycles or the timer triggers the expected execution.
The journal no longer contains the original failure after a representative test.

Operational context

A systemd timer can be healthy while its service fails, or the timer itself can be disabled, waiting on an unexpected calendar expression or delayed by persistence/boot behavior. Inspect the timer unit and its triggered service as two separate objects.

Step-by-step checks

List all timers and confirm the target timer has the expected NEXT/LAST timestamps and is loaded/enabled in the intended system or user scope.
Inspect the timer unit properties, OnCalendar or monotonic settings, Persistent behavior and the Unit it triggers.
Check the triggered service status and journal around the expected firing time; a successful timer activation does not prove the service command succeeded.
Verify timezone, clock synchronization and any RandomizedDelaySec/AccuracySec values before treating an apparently shifted execution time as a failure.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

systemctl list-timers --all

systemctl status example.timer

systemctl cat example.timer

journalctl -u example.timer -u example.service --since today

How to validate the result

The timer must schedule the expected next run and the associated service must execute successfully at a controlled test occurrence with matching journal evidence.

Evidence to keep

Keep timer and service unit names, NEXT/LAST values, unit contents/properties, journal timestamps, exit status and host timezone.

Frequently asked question

Why does the timer show as successful when my job did not run correctly?

The timer only activates the associated unit. The service can fail independently, so its status and journal must be checked separately.

Related BAOI resources: IT tools · procedures · IT dictionary.