Cours Linux / Vérifier les services systemd et les journaux du démarrage

Sur un système Linux dont le gestionnaire système est systemd, consultez l’état d’un service avec systemctl et les messages du même démarrage avec journalctl. Séparez son état actuel, comme active ou failed, de sa configuration d’activation, comme enabled ou disabled : ces informations répondent à deux questions différentes. Commencez par les consultations avant de décider de démarrer, arrêter ou reconfigurer un service.

Cette leçon vise les installations habituelles en machine virtuelle d’Ubuntu 26.04 LTS et de Rocky Linux 9, avec systemd comme processus 1. Les commandes à exécuter ici consultent les informations sans arrêter de service ni modifier les fichiers d’unité. Préparez la console et la vérification de l’environnement dans le cours de pratique Linux en machine virtuelle ; un conteneur ou un environnement particulier peut ne pas avoir le même gestionnaire système.

Situer systemd dans le démarrage de Linux

Dans un démarrage courant de PC ou de serveur, le micrologiciel initialise le matériel et transmet la main à un chargeur d’amorçage, qui charge le noyau et éventuellement un environnement initial. Certains micrologiciels peuvent aussi charger directement le noyau. Le noyau prépare l’exécution des processus ; l’environnement initial peut ensuite passer au système installé.

Le gestionnaire système systemd fonctionne alors comme PID 1, c’est-à-dire le processus portant l’identifiant 1 dans l’espace de noms concerné. Il active et supervise des unités, notamment des services. La description officielle du démarrage avec systemd détaille ce parcours, y compris l’environnement initial. Tous les environnements Linux ne suivent pas cette organisation.

ps -p 1 -o pid,comm,args
systemctl --version
systemctl get-default

La première commande permet de lire le nom et les arguments du processus 1. Vérifiez qu’il s’agit bien de systemd ; la présence du seul fichier systemctl ne suffit pas. Si le gestionnaire système n’est pas systemd ou si la connexion à son bus échoue dans votre environnement, ne poursuivez pas comme si les commandes administraient une machine classique.

--version identifie les outils installés. get-default indique la cible par défaut, pas une preuve que toutes ses fonctions sont actuellement opérationnelles. multi-user.target représente habituellement un système multiutilisateur sans interface graphique ; graphical.target ajoute le niveau graphique prévu par la distribution. Choisir une cible n’installe pas les logiciels manquants et sa présence ne prouve pas qu’un écran de connexion fonctionne.

Comprendre les unités et leurs relations

Une unité est un objet géré par systemd. Son suffixe indique son type : .service pour un service, .target pour regrouper ou synchroniser des unités, .socket pour une activation liée à un socket et .timer pour une activation dans le temps. Un paquet doit fournir les programmes et les unités nécessaires avant qu’un service puisse fonctionner ; le cours APT et DNF explique comment vérifier un paquet.

Les relations de besoin et d’ordre sont distinctes. After= règle un ordre lorsque les unités participent au démarrage ; il ne demande pas à lui seul de démarrer l’autre unité. Wants= ou Requires= expriment d’autres relations. La référence systemd.unit précise leur combinaison. Des unités peuvent se lancer en parallèle : une cible n’est pas une liste que systemd exécute simplement de haut en bas.

systemctl list-units --type=service --state=running --no-pager
systemctl --failed --no-pager
systemctl list-unit-files --type=service --no-pager

La première commande montre les unités de service chargées dont le sous-état correspond à running. La deuxième montre les unités en échec, sans se limiter forcément aux services. La troisième liste les fichiers d’unités de service et leur état d’activation. Une unité installée mais inactive ne figure pas nécessairement dans la première liste : les trois consultations ne recensent pas la même chose.

Relevez les noms complets réellement affichés. Une absence de service failed ne garantit pas qu’une application répond correctement : un processus peut être présent tandis qu’une requête échoue. Il faudra alors vérifier aussi la réponse attendue, le port pertinent et les messages de l’application.

Séparer l’état actuel et l’activation au démarrage

Un service peut être active tout en étant disabled : il a pu être démarré manuellement ou par une autre unité. Inversement, un service enabled peut être inactive ou failed. enabled exprime un raccordement à des mécanismes d’activation, souvent au démarrage, sans garantir que l’unité démarrera avec succès.

disabled ne bloque pas toutes les activations ; une dépendance ou un socket peut encore déclencher le service. masked représente un blocage plus fort. static indique l’absence de règles permettant un enable direct dans la section [Install] ; cela n’empêche pas une activation appropriée par d’autres unités. Ne transformez donc pas static en panne à corriger.

active ne signifie pas non plus toujours « un processus tourne en permanence ». Un service de type oneshot avec RemainAfterExit=yes peut rester actif après la fin de sa commande. La référence des types de services systemd explique ce cas. Pour un service continu, active (running) et active (exited) appellent des lectures différentes.

Examiner un service sans le modifier

Utilisons systemd-journald.service, le service de journalisation généralement présent sur ces installations. Nous allons seulement le consulter. Si l’unité n’existe pas dans votre environnement, vérifiez celui-ci et la liste des unités ; ne créez pas une unité de ce nom et n’arrêtez pas la journalisation pour reproduire un résultat.

systemctl status systemd-journald.service --no-pager --full
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

Dans status, lisez Loaded pour la définition trouvée, son chemin et les informations d’activation, puis Active pour l’état actuel et son sous-état. Un Main PID peut identifier le processus principal, et les lignes finales présentent des messages récents accessibles. --full évite certaines abréviations et --no-pager affiche directement la sortie ; sans ce dernier, un afficheur comme less peut s’ouvrir, que l’on quitte avec q.

Ne cherchez pas un numéro de PID ou une date identique à un exemple : ils dépendent de la machine. Un état actif est courant pour cette unité, et static peut être une configuration normale. Si la sortie indique failed, not-found ou un refus, lisez ce message comme une information à expliquer, sans supposer qu’une commande de consultation a cassé le service.

is-active donne l’état actuel et peut renvoyer un état de commande non nul lorsque l’unité n’est pas active. is-enabled répond à l’autre question ; certains états comme static ont un code de retour 0 sans vouloir dire enabled. Lisez le texte et la table de votre manuel au lieu de traiter chaque code comme un simple succès ou échec du démarrage. Le manuel de systemctl décrit ces états et les limites de status.

Pour lire séparément quelques propriétés plutôt que la présentation humaine de status :

systemctl show systemd-journald.service -p LoadState -p ActiveState -p SubState -p UnitFileState -p MainPID

Vous retrouvez des champs nommés, par exemple ActiveState et UnitFileState, ce qui facilite la comparaison des deux dimensions. Une propriété vide ou un résultat différent de celui attendu doit être interprété avec la version et la définition locale, sans inventer de valeur de remplacement. Les outils systemd évoluent ; le manuel livré pour Ubuntu 26.04 et man systemctl sur la machine permettent de contrôler les options disponibles.

Lire le journal du même démarrage

Le journal systemd rassemble des événements provenant notamment des services et du noyau. journalctl sélectionne les entrées accessibles. Pour comparer un problème au bon démarrage, commencez par le filtre -b :

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager

La première commande demande les 30 dernières entrées de ce démarrage associées à l’unité. La seconde demande les 30 dernières entrées de priorité warning ou plus importante, dans l’ensemble du journal accessible. -n limite le nombre d’entrées ; il ne représente pas une durée de 30 secondes. --no-pager évite une interface interactive.

Une absence d’entrée peut venir du filtre, des droits, de la rétention ou du fait qu’aucun message correspondant n’a été conservé. Elle ne prouve pas que le service n’a jamais démarré. Si les messages système sont inaccessibles, utilisez un compte ou une consultation élevée autorisée par votre politique, plutôt que d’assouplir les permissions des fichiers de journal.

Pour élargir la lecture de l’unité, répétez par exemple la première commande avec -n 100 à la place de -n 30. Cette variation ne change que la limite demandée : elle ne fabrique pas des entrées inexistantes et ne change pas les messages. Revenez ensuite à -n 30 si vous souhaitez retrouver le même cadrage.

Lisez l’heure, le composant et le texte complet, ainsi que les événements voisins. Une alerte de résolution réseau et l’arrêt d’une application au même moment peuvent être liés, mais leur proximité ne suffit pas à prouver la cause. Le manuel de journalctl définit les filtres de démarrage, d’unité, de priorité et de nombre d’entrées.

Rechercher les journaux d’un démarrage précédent

journalctl --list-boots --no-pager

La liste donne les démarrages encore présents dans les journaux accessibles, avec leur identifiant et leurs bornes de temps. Vérifiez-la avant de demander un démarrage précédent. Si celui-ci est bien disponible, la commande suivante consulte ses dernières entrées :

journalctl -b -1 -n 30 --no-pager

Dans la consultation habituelle du journal local, -b -1 désigne le démarrage précédant le dernier enregistré. Contrôlez les heures et l’identifiant si vous analysez des journaux copiés d’une autre machine ou incomplets. Une unité précise peut être ajoutée avec le même -u que précédemment.

L’absence d’un ancien démarrage ne démontre pas qu’il n’a pas eu lieu. Les journaux peuvent être volatils, supprimés par la rétention, limités par l’espace ou inaccessibles au compte. La configuration de journald décrit les modes de stockage et les limites. Changer la conservation aujourd’hui ne recrée pas les messages déjà perdus.

Choisir une modification en comprenant son effet

Les commandes suivantes sont des formes de référence, pas une liste à exécuter sur systemd-journald. NOM.service représente une unité réellement identifiée et autorisée à être modifiée. Sur une machine distante, arrêter le service de connexion ou de réseau peut couper l’accès ; prévoyez la console de récupération et une fenêtre adaptée.

enable --now demande à la fois les liens d’activation et le démarrage ; ce sont deux effets à contrôler séparément. Pour une définition d’unité modifiée manuellement sur disque, daemon-reload fait prendre en compte cette définition par le gestionnaire. Il ne remplace pas le reload de l’application ni son restart. Certaines commandes, comme systemctl edit, font elles-mêmes la relecture du gestionnaire après édition.

Avant tout changement réel, relevez l’état initial, les fichiers concernés et les dépendances, puis préparez la sauvegarde et la procédure de retour adaptée au service. disable peut retirer davantage de liens qu’un enable précédent n’en a créés : inverser un verbe ne garantit pas une restauration exacte. Ne multipliez pas restart pour effacer un symptôme sans lire les messages.

Rapprocher l’état, les messages et le symptôme

1. Identifiez la machine, son démarrage et le nom exact de l’unité. Confirmez la présence du programme et de sa définition.
2. Lisez status pour distinguer définition introuvable, unité inactive et échec. Relevez l’heure, le résultat et le processus concernés avant de changer quoi que ce soit.
3. Consultez journalctl avec le même démarrage et la même unité. Élargissez le nombre d’entrées si le contexte est tronqué.
4. Suivez les indices précis : fichier de configuration invalide, ressource manquante, permission refusée, port occupé ou dépendance défaillante. Vérifiez le point désigné au lieu de rendre arbitrairement tous les fichiers accessibles.
5. Après sauvegarde et correction ciblée, réalisez l’action nécessaire au moment autorisé. Vérifiez à nouveau l’état, les nouvelles entrées et la réponse réelle de l’application.

Par exemple, si l’unité est enabled mais failed et que ses messages désignent une erreur de syntaxe dans un fichier, ajouter un nouvel enable ne répare pas ce fichier. À l’inverse, si le service est active mais qu’une requête échoue, commencez par le symptôme applicatif et son contexte ; changer l’activation au démarrage ne répond pas à cette question.

Interpréter les mesures de durée du démarrage

systemd-analyze critical-chain
systemd-analyze blame

critical-chain présente une chaîne d’unités sensible aux durées de démarrage. Dans sa présentation, @ situe l’activation et + la durée indiquée pour l’unité. blame classe des durées d’initialisation ; le plus grand nombre n’identifie pas à lui seul la cause du temps total.

Une unité peut attendre une autre ressource, plusieurs démarrages peuvent se chevaucher et ces vues ne mesurent pas tous les types d’attente ni toute la disponibilité applicative. Les activations par socket et les services considérés démarrés immédiatement demandent notamment du contexte. Le manuel de systemd-analyze explique ces limites. Recoupez les durées avec les relations d’unités, les horodatages et le problème réellement observé avant de désactiver un service.