Systemd : comprendre un service et son timer

01. Observer avant de relancer

systemctl status nom.service
systemctl cat nom.service
journalctl -u nom.service --since today --no-pager

Remplacez nom.service par l’unité concernée. Le statut donne un aperçu, tandis que le journal aide à comprendre la séquence. Regardez le premier échec utile plutôt que le dernier message d’une cascade. Le compte utilisateur, le répertoire de travail et les chemins absolus expliquent souvent une différence avec une exécution interactive.

02. Distinguer le déclencheur et le travail

Le fichier .timer détermine quand démarrer une unité. Le fichier .service décrit le travail à effectuer. Pour une commande qui se termine, un service de type oneshot est généralement adapté. Le script doit renvoyer un code d’échec quand le travail échoue.

systemctl list-timers --all
systemctl status nom.timer
systemctl show nom.service -p Result -p ExecMainStatus

Un timer actif ne prouve pas que sa tâche a réussi. Vérifiez séparément la dernière exécution du service et la fraîcheur du résultat produit. Pour une sauvegarde, cela signifie vérifier le dernier point de restauration utilisable.

03. Anticiper les absences et les chevauchements

Documentez le fuseau horaire du serveur et le comportement attendu après une interruption. L’option Persistent=true, pour un timer basé sur OnCalendar, permet de rattraper un déclenchement manqué pendant son inactivité. Décidez si ce rattrapage est souhaitable lorsque la machine redémarre en pleine journée.

Le timer ne redémarre pas une unité déjà active. Si un même script peut aussi être lancé manuellement ou par un autre ordonnanceur, ajoutez un mécanisme de verrouillage adapté. Testez le cas d’une exécution plus longue que prévu.

04. Faire remonter les échecs

Ajoutez une alerte sur l’échec, mais aussi sur l’absence d’exécution réussie depuis une durée maximale. Ce second contrôle détecte les timers désactivés et les machines silencieuses. Les journaux doivent rester consultables assez longtemps pour expliquer une panne constatée plusieurs jours après.

Après une modification, vérifiez la syntaxe de l’unité, rechargez systemd et réalisez une exécution contrôlée. Notez la procédure de retour arrière et l’emplacement des fichiers. Le guide des journaux Linux complète ce diagnostic.

05. Remplacer un squelette SysV par une unité adaptée

Le squelette « Daemon - syntaxe » du wiki imprimait des messages start et stop puis retournait zéro. Ce n’était pas un gestionnaire complet de processus : il manquait la preuve du démarrage, l’identification du processus et la propagation des erreurs.

Pour un service géré par systemd, décrivez le programme, le compte, les fichiers et le comportement d’arrêt dans une unité adaptée. Ne le faites pas passer artificiellement en arrière-plan si son mode normal permet au superviseur de le suivre. After définit un ordre ; il ne crée pas à lui seul la dépendance ou la disponibilité applicative. Vérifiez les relations Wants ou Requires et la méthode de signalement de disponibilité.