Timer systemd qui ne se déclenche pas : diagnostiquer le calendrier et le service

ParKelvin Carretero-Corrales

Un rapport absent ou une synchronisation en retard ne prouve pas que le planificateur est en panne. Pour diagnostiquer un timer systemd, séparez trois questions : quelle échéance était prévue, le service a-t-il été activé et le traitement a-t-il produit le résultat attendu ? Cette séparation évite les relances qui créent des doublons.

La procédure ci-dessous concerne des unités système Linux. Remplacez mon-traitement par le nom réel. Pour des unités utilisateur, utilisez le compte concerné et les variantes --user de systemctl et journalctl. Consultez les manuels installés si une option diffère selon votre version.

Réponse rapide : commencer par des contrôles en lecture seule

systemctl list-timers --all mon-traitement.timer
systemctl status mon-traitement.timer mon-traitement.service --no-pager --full
systemctl cat mon-traitement.timer mon-traitement.service
journalctl -u mon-traitement.timer -u mon-traitement.service --since '24 hours ago' --no-pager -o short-iso

Dans la liste, relevez NEXT, LAST et ACTIVATES. Dans le statut, cherchez l’état du timer et celui du service. Dans les journaux, repérez le début, la fin et la première erreur du traitement. Ne diffusez pas une sortie complète sans la relire : configuration et journaux peuvent contenir des informations sensibles.

1. Vérifier le bon timer et le bon service

list-timers affiche les timers chargés en mémoire, pas un inventaire exhaustif des fichiers installés. Pour compléter :

systemctl list-unit-files mon-traitement.timer
systemctl is-enabled mon-traitement.timer
systemctl is-active mon-traitement.timer

enabled décrit l’activation configurée, pas une preuve de fonctionnement actuel. active ne prouve pas davantage la réussite métier. Comparez ces informations au service indiqué par ACTIVATES : par défaut, mon-traitement.timer active mon-traitement.service, mais Unit= peut changer cette cible.

systemctl cat montre le fichier principal et les compléments de configuration sur disque. Après une édition, leur contenu peut différer de la configuration déjà chargée tant qu’un daemon-reload n’a pas eu lieu.

2. Tester OnCalendar sans attendre la prochaine échéance

Pour exprimer « tous les jours à 8 heures, heure de Paris », une expression possible est :

OnCalendar=*-*-* 08:00:00 Europe/Paris

Les expressions calendaires acceptent un fuseau IANA. Sans fuseau explicite, l’heure locale du système compte : un VPS réglé en UTC ne suit donc pas implicitement votre montre française. Pour comparer des observations, conservez toujours la date et le fuseau, pas seulement « 8 h ».

systemd-analyze calendar --iterations=3 '*-*-* 08:00:00 Europe/Paris'

Cette commande normalise l’expression et calcule ses prochaines occurrences ; elle n’exécute pas le service. Vérifiez la forme normalisée et les instants affichés. Attention : l’affichage peut être converti dans le fuseau local de la machine de diagnostic, différent de celui inscrit dans l’expression.

Pour examiner une période précise, notamment autour d’un changement d’heure, utilisez une date de référence :

systemd-analyze calendar --base-time='2026-10-24 00:00:00 Europe/Paris' --iterations=3 '*-*-* 08:00:00 Europe/Paris'

Ce calcul ne valide pas à lui seul le timer déployé : il teste l’expression fournie. Il ne tient pas compte de l’état du service ni de la réussite du programme. Les expressions systemd ont leur propre syntaxe ; ne recopiez pas une ligne cron telle quelle.

3. Comprendre ce que Persistent rattrape

Persistent=true ne concerne que les timers avec OnCalendar=. À la réactivation du timer, une activation de rattrapage peut avoir lieu si au moins une échéance a été manquée pendant son inactivité. Ce n’est pas un rejeu distinct de chaque occurrence ; RandomizedDelaySec= peut encore retarder ce rattrapage.

Conséquence pratique : si votre application doit traiter trois journées oubliées, elle doit identifier elle-même les périodes manquantes. Gardez un suivi métier des lots traités et rendez la reprise tolérante aux doublons. Le calendrier ne remplace pas cette logique.

4. Examiner le piège du service déjà actif

À l’échéance, un service déjà actif n’est pas redémarré et aucune nouvelle instance n’est créée. C’est notamment un piège avec RemainAfterExit=yes.

systemctl show mon-traitement.service -p Type -p ActiveState -p SubState -p RemainAfterExit -p Result -p ExecMainCode -p ExecMainStatus

Pour un traitement court, Type=oneshot permet à systemd d’attendre la fin de la commande. Sans RemainAfterExit=yes, le service peut ensuite apparaître inactive (dead) : ce n’est pas, à lui seul, un échec. À l’inverse, active (exited) peut signifier que l’unité reste considérée active alors que son processus s’est terminé.

Ne changez pas ce réglage à l’aveugle : certains services utilisent volontairement cet état pour représenter une configuration appliquée. Pour votre tâche périodique, vérifiez plutôt si le modèle choisi correspond à un travail terminé ou à un service permanent.

5. Reconstituer l’exécution dans les journaux

journalctl -u mon-traitement.service --since '24 hours ago' --no-pager -o short-iso
journalctl -u mon-traitement.timer --since '24 hours ago' --no-pager -o short-iso

Le filtre -u cible l’unité ; --since borne la période. Le format short-iso facilite la comparaison des horodatages. Si le problème est antérieur, élargissez la fenêtre avant de conclure à une absence d’exécution.

Cherchez une séquence exploitable : demande de démarrage, sortie du programme, fin ou erreur. Un journal vide peut aussi refléter des droits de lecture insuffisants ou un historique indisponible. Faites vérifier l’accès par un administrateur autorisé si nécessaire.

Même un code de sortie réussi ne garantit pas qu’un fichier a été envoyé ou qu’une sauvegarde est restaurable. Contrôlez un résultat concret : date du rapport, nombre d’éléments traités ou accusé de réception. C’est ce contrôle qui transforme un simple déclenchement en preuve de service rendu.

6. Distinguer retard prévu et incident

AccuracySec= autorise une fenêtre de déclenchement, d’une minute par défaut. RandomizedDelaySec= ajoute un délai aléatoire. Ces réglages peuvent expliquer un décalage sans panne ; ils ne garantissent pas une exécution à la seconde près.

Avant de réduire les délais, formulez le besoin : « disponible avant 8 h 30 » n’impose pas la même précision que « démarrer exactement à 8 h ». Comparez ensuite l’heure observée à la configuration, plutôt qu’à une attente implicite.

7. Corriger puis vérifier sans provoquer de doublon

Avant toute réactivation, assurez-vous qu’un rattrapage ou une relance ne renverra pas un mail, une facture ou un transfert déjà effectué. Conservez la configuration de départ et choisissez une fenêtre d’intervention si le traitement a des effets externes.

Si les unités sont installées à ces emplacements, vérifiez-les avec :

systemd-analyze verify /etc/systemd/system/mon-traitement.timer /etc/systemd/system/mon-traitement.service

Adaptez les chemins aux fichiers réels. Corrigez les erreurs signalées ; ce contrôle ne remplace pas un test fonctionnel du programme.

Après une modification validée, un administrateur peut recharger la configuration puis redémarrer le timer :

sudo systemctl daemon-reload
sudo systemctl restart mon-traitement.timer

Cette dernière étape modifie l’état du système et peut entraîner un rattrapage. Vérifiez ensuite la prochaine échéance, les journaux et le résultat métier. Ne démarrez pas manuellement le service uniquement pour « voir » si son action n’est pas réversible.

Conclusion : une échéance n’est pas un résultat

Le diagnostic devient plus simple quand on suit la chaîne dans l’ordre : calendrier attendu, état du timer, état du service, puis preuve du traitement. Gardez dans votre compte rendu l’expression testée, le fuseau, l’heure observée et le résultat obtenu. Ce sont des éléments plus utiles qu’un redémarrage isolé qui efface le contexte.

Sources

Les sources en ligne suivent la branche principale du projet. Vérifiez aussi les pages de manuel de votre distribution avec man systemd.timer, man systemd.service et man systemd-analyze.

Publications similaires