Diagnostique un service avec systemctl et journalctl

L’idée reçue

« Si systemctl status affiche failed, il suffit de redémarrer plusieurs fois. »

Le redémarrage répété efface rarement la cause. Il faut d’abord lire l’état structuré, le code de sortie, la commande exécutée et les journaux correspondants.

01Émets des journaux sans unité

./module4-systemd-boot-lab.sh emit
export LAB="/tmp/soria-linux-systemd-$USER"
cat "$LAB/logs/agent.stdout.log"
cat "$LAB/logs/agent.stderr.log"

Lorsque le socket journald est disponible, le lab soumet aussi ces messages avec l’identifiant soria-linux-lab.

journalctl -t soria-linux-lab --since '-10 min' --no-pager

02Installe le service défaillant en mode utilisateur

mkdir -p "$HOME/.config/systemd/user"
cp "$LAB/units/soria-agent-failing.service" "$HOME/.config/systemd/user/soria-agent-failing.service"
systemctl --user daemon-reload
systemctl --user start soria-agent-failing.service || true

L’échec est volontaire. L’agent écrit sur stdout et stderr, puis retourne le code 23.

03Lis l’état structuré

systemctl --user status soria-agent-failing.service --no-pager || true
systemctl --user show soria-agent-failing.service -p LoadState -p ActiveState -p SubState -p Result -p ExecMainCode -p ExecMainStatus -p FragmentPath -p ExecStart

Champ

Question

Exemple attendu

LoadState

l’unité est-elle chargée ?

loaded

ActiveState

état de haut niveau

failed

Result

catégorie de fin

exit-code

ExecMainStatus

code retourné

23

04Filtre le journal

journalctl --user -u soria-agent-failing.service --since '-10 min' --no-pager
journalctl --user -u soria-agent-failing.service -p warning..alert --no-pager
journalctl --user -u soria-agent-failing.service -o short-iso --no-pager

Commence par l’unité et une fenêtre temporelle. Ajoute ensuite priorité, boot ou format. Un filtre trop étroit peut masquer la ligne qui explique l’échec.

05Vérifie la définition réellement chargée

systemctl --user cat soria-agent-failing.service
systemctl --user show soria-agent-failing.service -p EnvironmentFiles -p ExecStart -p User -p Group
systemd-analyze verify "$HOME/.config/systemd/user/soria-agent-failing.service"

Une unité peut être syntaxiquement valide et échouer à l’exécution. Ici, le code 23 vient volontairement de l’application, pas de systemd.

06Corrige la cause

sed -i 's/ soria-agent.sh fail/ soria-agent.sh once/' "$HOME/.config/systemd/user/soria-agent-failing.service"
systemd-analyze verify "$HOME/.config/systemd/user/soria-agent-failing.service"
systemctl --user daemon-reload
systemctl --user restart soria-agent-failing.service
systemctl --user show soria-agent-failing.service -p ActiveState -p SubState -p Result -p ExecMainStatus

07Réinitialise et nettoie

systemctl --user reset-failed soria-agent-failing.service
rm -f "$HOME/.config/systemd/user/soria-agent-failing.service"
systemctl --user daemon-reload
systemctl --user reset-failed

Challenge autonome

Écris une fiche d’incident systemd

Consigne horodatage, unité, état, code de sortie, commande réelle, trois lignes de journal pertinentes, hypothèse, correction, preuve de retour au succès et commande de rollback.

✓Ce que tu retiens

Le diagnostic combine état structuré, définition chargée, code de sortie et journal. reset-failed nettoie l’état mémorisé après correction ; il ne corrige pas la cause.