Introduction
Un processus est un programme en cours d’exécution. Un service est une fonction système de longue durée, gérée conformément à une définition et à des règles de cycle de vie. Sous Ubuntu, systemd lit les définitions d’unités, démarre et arrête les services, suit leur état et enregistre leur sortie dans le journal système.
Dans ce laboratoire, vous utiliserez le service de pratique isolé labex-heartbeat. Vous examinerez son unité, contrôlerez son état d’exécution, configurerez son activation au démarrage, consulterez le journal système et les journaux texte traditionnels, suivrez les sorties en temps réel, diagnostiquerez une défaillance contrôlée et rétablirez un fonctionnement normal. Vous ne modifierez aucun fichier d’unité et n’interviendrez pas sur le service SSH.
Identifier systemd et les unités de service
Dans cette étape, vous vérifierez que systemd est disponible et distinguerez les unités en cours d’exécution des fichiers d’unités installés.
Accédez à l’espace de travail du laboratoire :
cd /home/labex/project/service-lab
Affichez la version de systemd. La première ligne suffit pour l’identifier :
systemctl --version | head -n 1
Demandez à systemd son état général :
systemctl is-system-running || true
La valeur running signifie que toutes les unités requises fonctionnent correctement. Une machine virtuelle de formation peut afficher degraded lorsqu’une unité facultative sans rapport avec ce laboratoire a échoué ; cette commande confirme néanmoins que systemd répond correctement.
Affichez un échantillon des services actuellement en cours d’exécution :
systemctl list-units --type=service --state=running --no-pager | head -n 12
Une unité est un objet géré par systemd. Les unités de service se terminent par .service. Les fichiers d’unités décrivent ce qui peut être géré, même lorsque l’élément concerné n’est pas actuellement en cours d’exécution :
systemctl list-unit-files --type=service --no-pager | head -n 12
Enregistrez un résumé concis de systemd. La substitution de commande $(...) insère la sortie d’une commande dans le texte écrit par printf :
printf 'systemd=%s\nstate=%s\n' "$(systemctl --version | head -n 1)" "$(systemctl is-system-running)" > systemd-summary.txt
cat systemd-summary.txt
Examiner la définition et l’état d’un service
Dans cette étape, vous examinerez le service de pratique préparé avant de le démarrer.
systemctl status regroupe le chemin de l’unité chargée, son activation, son état d’exécution, les informations sur le processus et les dernières lignes du journal :
cd /home/labex/project/service-lab
systemctl status labex-heartbeat.service --no-pager
Le service devrait être inactive (dead) et disabled. L’état inactif signifie qu’il n’est pas actuellement en cours d’exécution ; l’état désactivé signifie qu’il n’est pas configuré pour être lancé au démarrage via sa cible d’installation. Il s’agit de deux propriétés distinctes.
Affichez la définition de l’unité :
systemctl cat labex-heartbeat.service
La section [Unit] décrit l’identité et l’ordre de démarrage, [Service] définit le processus et [Install] décrit l’activation. Vous vous contentez d’examiner cette unité préparée ; il n’est pas nécessaire d’en créer une.
Utilisez systemctl show pour afficher des propriétés lisibles par une machine :
systemctl show labex-heartbeat.service -p LoadState -p ActiveState -p SubState -p UnitFileState
Enregistrez ces propriétés pour vérification :
systemctl show labex-heartbeat.service -p LoadState -p ActiveState -p SubState -p UnitFileState > service-properties.txt
cat service-properties.txt
Démarrer, arrêter et redémarrer un service
Dans cette étape, vous modifierez l’état d’exécution du service de pratique et vérifierez chaque résultat.
Le démarrage et l’arrêt des services système nécessitent des privilèges élevés. Démarrez le service :
sudo systemctl start labex-heartbeat.service
Vérifiez brièvement son état actif :
systemctl is-active labex-heartbeat.service
La sortie attendue est active. Affichez ensuite l’état détaillé :
systemctl status labex-heartbeat.service --no-pager
L’état contient désormais un PID principal. Arrêtez le service et examinez le résultat :
sudo systemctl stop labex-heartbeat.service
systemctl is-active labex-heartbeat.service || true
L’état attendu est inactive. Démarrez-le à nouveau, puis utilisez restart pour remplacer le processus en cours en une seule opération :
sudo systemctl start labex-heartbeat.service
sudo systemctl restart labex-heartbeat.service
systemctl show labex-heartbeat.service -p ActiveState -p SubState -p MainPID
À la fin de cette étape, le service doit présenter ActiveState=active et SubState=running.
Configurer l’activation au démarrage
Dans cette étape, vous distinguerez l’état d’exécution actuel d’un service de son activation pour les prochains démarrages.
Le service est actif depuis l’étape précédente, mais sa configuration initiale laissait son fichier d’unité désactivé. Vérifiez son activation :
systemctl is-enabled labex-heartbeat.service || true
Activez le service :
sudo systemctl enable labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service
L’activation crée des liens qui rattachent le service à une cible de démarrage. Elle ne redémarre pas un service déjà en cours d’exécution.
Entraînez-vous à supprimer ces liens de démarrage :
sudo systemctl disable labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service || true
Le service peut rester actif même si la sortie indique maintenant disabled. Réactivez-le pour rétablir l’état final du laboratoire :
sudo systemctl enable labex-heartbeat.service
Confirmez ces deux propriétés indépendantes :
systemctl is-active labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service
Consulter les journaux d’un service avec journalctl
Dans cette étape, vous lirez les sorties récentes du service dans le journal systemd et enregistrerez un instantané ciblé.
Les services gérés par systemd envoient généralement leur sortie standard et leur sortie d’erreur standard dans le journal. Consultez uniquement l’unité de pratique :
sudo journalctl -u labex-heartbeat.service -n 10 --no-pager
L’option -u sélectionne une unité, -n 10 conserve les dix entrées les plus récentes et --no-pager les affiche directement. Vous devriez voir le message de démarrage du service ainsi que les signaux de pulsation.
Limitez les résultats à une période récente :
sudo journalctl -u labex-heartbeat.service --since "5 minutes ago" --no-pager
Filtrez les messages dont la priorité est au moins égale à « avertissement ». Une absence de sortie est un résultat normal et valide si le service n’a enregistré aucun avertissement :
sudo journalctl -u labex-heartbeat.service -p warning --since "5 minutes ago" --no-pager
Enregistrez un instantané récent limité à cette unité dans l’espace de travail du projet :
cd /home/labex/project/service-lab
sudo journalctl -u labex-heartbeat.service -n 20 --no-pager > service-journal.txt
tail -n 5 service-journal.txt
Suivre un journal texte traditionnel
Dans cette étape, vous examinerez /var/log et suivrez un journal texte pendant l’arrivée de nouvelles entrées.
La hiérarchie /var/log contient de nombreux journaux système et applicatifs traditionnels. Affichez-en un petit échantillon :
ls -lh /var/log | head -n 12
Lisez les dernières entrées du service de pratique :
tail -n 5 /var/log/labex-heartbeat.log
L’option -f suit un fichier et affiche les nouvelles lignes ajoutées par un autre processus :
tail -f /var/log/labex-heartbeat.log
Attendez l’apparition d’au moins deux nouvelles lignes de pulsation, puis appuyez sur Ctrl+C. Cela interrompt tail, mais n’arrête pas le service qui écrit dans le journal.
Filtrez les lignes de pulsation et affichez les trois plus récentes :
grep '^heartbeat ' /var/log/labex-heartbeat.log | tail -n 3
Enregistrez un échantillon de cinq lignes dans l’espace de travail du projet :
cd /home/labex/project/service-lab
tail -n 5 /var/log/labex-heartbeat.log > traditional-log-sample.txt
cat traditional-log-sample.txt
Diagnostiquer et récupérer un service défaillant
Dans cette étape, vous provoquerez une défaillance de configuration contrôlée, utiliserez l’état du service et les journaux pour l’identifier, puis rétablirez un fonctionnement normal.
Arrêtez le service de pratique et sauvegardez sa configuration simple :
sudo systemctl stop labex-heartbeat.service
sudo cp /etc/labex-heartbeat.conf /etc/labex-heartbeat.conf.bak
Remplacez l’intervalle numérique par une valeur invalide. Cette modification ne perturbe volontairement que le service de pratique :
sudo sed -i 's/^INTERVAL=2$/INTERVAL=invalid/' /etc/labex-heartbeat.conf
Tentez de démarrer le service. Un message d’échec est attendu :
sudo systemctl start labex-heartbeat.service || true
Examinez l’état d’échec :
systemctl status labex-heartbeat.service --no-pager || true
systemctl is-failed labex-heartbeat.service
L’état vous indique que le processus s’est arrêté, mais le journal fournit la cause propre à l’application :
sudo journalctl -u labex-heartbeat.service -n 10 --no-pager
Recherchez le message configuration error: INTERVAL must be a positive integer. Restaurez la configuration correcte, effacez l’état d’échec enregistré, puis redémarrez le service :
sudo mv /etc/labex-heartbeat.conf.bak /etc/labex-heartbeat.conf
sudo systemctl reset-failed labex-heartbeat.service
sudo systemctl start labex-heartbeat.service
Confirmez la récupération :
systemctl is-active labex-heartbeat.service
cat /etc/labex-heartbeat.conf
Le service doit être active et la configuration doit de nouveau contenir INTERVAL=2.
Résumé
Vous avez distingué les processus, les services, l’état actif et l’activation au démarrage. Vous avez examiné une unité systemd, contrôlé un service de pratique sans risque avec systemctl et consulté ses entrées avec journalctl.
Vous avez également examiné /var/log, suivi une sortie texte en temps réel avec tail -f, utilisé conjointement l’état et les journaux pour expliquer une défaillance contrôlée, puis restauré le service. Cette méthode, qui consiste à examiner d’abord l’état puis les journaux, constitue une base pratique pour le dépannage des services destiné aux débutants.
