Définition simple
Un mécanisme systemd qui planifie l’exécution de services.
Définition technique
Les unités .timer déclenchent des unités .service selon une planification calendrier ou relative.
À quoi cela sert ?
Remplacer ou compléter cron avec une intégration systemd.
Exemple concret
Un timer peut lancer un script de sauvegarde tous les jours à 2h.
Problèmes fréquents
- Timer activé mais service absent
- Timezone mal comprise
- Persistent non configuré
Termes associés
À retenir : les comportements et commandes précises peuvent varier selon les versions, produits et architectures.
Approfondissement et preuve primaire
Un timer systemd programme l’activation d’une unité, généralement un service, selon une échéance monotone ou calendaire. Il sépare la planification du travail lui-même : le fichier `.timer` définit quand déclencher, tandis que le `.service` définit l’action. Des options comme `Persistent`, `RandomizedDelaySec` ou les dépendances peuvent modifier sensiblement le comportement après un redémarrage.
Vérification approfondie
Pour diagnostiquer un déclenchement absent, vérifier l’état du timer, la prochaine échéance calculée, le nom de l’unité activée et le résultat du service associé. Comparer l’expression `OnCalendar` au fuseau réellement utilisé et contrôler si une exécution ratée doit être rejouée avec `Persistent=true`. Les journaux du timer et du service doivent être lus séparément.
Critère de validation
Le timer est validé lorsque `systemctl list-timers` affiche l’échéance attendue, que l’unité cible s’exécute au bon moment et que son code de sortie est conforme. Pour une tâche critique, tester aussi le scénario de redémarrage ou d’indisponibilité afin de confirmer le comportement prévu face à une échéance manquée.
Référence primaire : systemd — systemd.timer manual.