Bonjour !
Dans la leçon précédente, nous avons appris à diagnostiquer les problèmes de connectivité réseau. Vous savez maintenant comment déterminer si un serveur est joignable en utilisant des outils comme ping et mtr. Mais que se passe-t-il si ping répond, que mtr montre un chemin clair, mais que l'application, par exemple un site web, reste inaccessible ?
C'est là que nous passons de l'enquêteur réseau à l'enquêteur système. Le problème ne vient pas du chemin, mais de l'application elle-même qui ne tourne pas correctement sur le serveur.
L'objectif de cette leçon est de vous apprendre à diagnostiquer et résoudre des problèmes de services applicatifs courants. Nous allons découvrir comment vérifier si un service est arrêté, comprendre pourquoi il a échoué grâce aux journaux, et le remettre en marche. C'est une compétence fondamentale que vous utiliserez tous les jours en tant qu'administrateur systèmes.
1. La gestion des services avec systemd et systemctl
Sur les systèmes Linux modernes comme Ubuntu, les applications qui tournent en arrière-plan (serveurs web, bases de données, etc.) sont gérées par un système appelé systemd. On appelle ces applications des services ou des démons (daemons). Pour interagir avec systemd, nous utilisons principalement la commande systemctl.
Avant d'aller plus loin, il est crucial de comprendre la terminologie.
systemd et systemctl : gérer les services Linux
Cet article de Stéphane Robert est une excellente référence sur systemd. Nous allons commencer par clarifier quelques termes essentiels qui prêtent souvent à confusion pour les débutants.
Lisez la section "Glossaire rapide (2 minutes)" et portez une attention particulière au tableau et à la sous-section "Les deux états à ne pas confondre". Vous devez bien comprendre la différence entre un service actif (active) et un service activé (enabled).
Pour résumer :
- Actif (
active) : Le service est en cours d'exécution maintenant. - Activé (
enabled) : Le service est configuré pour démarrer automatiquement au prochain démarrage du serveur.
Un service peut donc être active mais disabled (il tourne, mais ne redémarrera pas tout seul), ou inactive mais enabled (il est arrêté, mais démarrera au prochain boot).
Les commandes de base pour gérer un service sont très directes. La vidéo suivante vous en fera une démonstration claire.
How To Manage Linux Services with systemctl and journalctl | Sysadmin Basics
Cette vidéo d'Akamai Developer montre de manière pratique comment utiliser systemctl pour gérer un service (ici, le serveur web Apache).
Regardez les portions de la vidéo de 01:08 à 06:08. Concentrez-vous sur les commandes suivantes et ce qu'elles accomplissent : systemctl status apache2 : Pour vérifier l'état. systemctl start apache2 : Pour démarrer le service. systemctl stop apache2 : Pour l'arrêter. systemctl enable apache2 et systemctl disable apache2 : Pour contrôler son démarrage automatique.
2. Le diagnostic : quand un service refuse de démarrer
Le vrai travail de dépannage commence lorsqu'un service est à l'état inactive (dead) ou, pire, failed. Le simple fait de le redémarrer avec systemctl start ne fonctionnera souvent pas. Il faut comprendre pourquoi il a échoué.
La sortie de systemctl status <nom_du_service> vous donne déjà un indice précieux : les dernières lignes du journal associées au service. Mais pour une enquête approfondie, nous devons utiliser l'outil que nous avons déjà croisé : journalctl.
How To Manage Linux Services with systemctl and journalctl | Sysadmin Basics
Retournons à notre vidéo pour voir comment utiliser journalctl afin d'isoler les logs d'un service spécifique.
Regardez la vidéo de 07:36 à 10:24. La partie la plus importante pour nous est l'option -u (pour unit), qui permet de filtrer les journaux pour un seul service, comme dans journalctl -u apache2.
3. Étude de cas : dépanner un service défaillant
Mettons maintenant cette méthodologie en pratique. Nous allons analyser un scénario très réaliste : un administrateur crée un nouveau service, mais celui-ci ne démarre pas à cause d'une erreur de configuration.
L'article suivant décrit parfaitement la méthode de diagnostic à suivre.
Maitriser la gestion des services Linux avec systemd
Cette section de la FAQ d'un article de Stéphane Robert est un mini-guide de dépannage parfait. Lisez-le attentivement, car il résume la procédure que nous allons appliquer.
Lisez la section "Comment diagnostiquer un service qui ne démarre pas ?" dans les "Questions fréquentes". Retenez les 4 étapes : Vérifier l'état -> Consulter les logs -> Vérifier la syntaxe -> Tester manuellement. Le tableau des erreurs fréquentes est aussi très utile.
Maintenant, observons cette méthodologie en action. La vidéo ci-dessous montre un administrateur qui crée un service, rencontre une erreur, utilise journalctl pour la diagnostiquer, corrige le problème et relance le service avec succès.
How To Create a Simple Systemd Service?
Cette vidéo de BugX est un cas pratique parfait. Elle illustre l'ensemble du processus de dépannage que nous venons d'apprendre.
Regardez la vidéo de 08:33 à 15:23. Suivez bien les étapes : Il vérifie le statut et voit que le service a échoué (systemctl status). Il utilise journalctl -u ... pour lire les logs d'erreur. Il identifie la cause : l'utilisateur spécifié dans le fichier de service n'existe pas. Il corrige le problème en créant l'utilisateur (useradd). Il recharge la configuration de systemd (daemon-reload) et démarre le service avec succès.
Ce cas pratique illustre un point crucial : les journaux sont votre meilleur ami. L'erreur code=exited, status=217/USER pointait sans ambiguïté vers un problème d'utilisateur. Savoir lire et interpréter ces messages est la clé.
4. Résolution avancée : rendre les services plus robustes
Un bon administrateur ne se contente pas de réparer les pannes, il essaie aussi de les prévenir ou d'en minimiser l'impact. systemd permet de configurer un service pour qu'il redémarre automatiquement en cas d'échec.
Maitriser la gestion des services Linux avec systemd
Pour finir, découvrons comment rendre nos services plus résilients. Cette configuration est très courante en entreprise pour assurer une haute disponibilité des applications.
Lisez la section "Comment redémarrer automatiquement un service qui plante ?". Comprenez le rôle des directives Restart= et RestartSec= dans un fichier de service.
Configurer Restart=on-failure est une solution simple et efficace pour qu'un service qui plante à cause d'un problème temporaire (par exemple, un pic de mémoire) puisse se relancer tout seul, sans intervention manuelle.
Conclusion
Aujourd'hui, vous avez ajouté une compétence essentielle à votre panoplie d'administrateur système. Vous savez maintenant comment aborder un des problèmes les plus courants : une application qui ne répond pas.
Points clés à retenir :
- La boucle de dépannage d'un service :
systemctl status servicepour un aperçu rapide.journalctl -u service -epour lire les journaux d'erreurs en détail (le-evous amène directement à la fin).- Identifier la cause à partir des messages d'erreur (fichier de configuration manquant, permission incorrecte, etc.).
- Corriger le problème.
systemctl restart servicepour relancer.systemctl status servicepour vérifier que le service est bienactive (running).
systemdest votre centre de contrôle :systemctlest l'outil pour interagir avec les services, etjournalctlest votre loupe pour examiner ce qui s'est mal passé.- Pensez à la résilience : Utiliser des options comme
Restart=on-failurepermet de construire des systèmes plus robustes qui peuvent se réparer eux-mêmes dans certains cas.
Dans la prochaine leçon, nous allons prendre un peu de recul par rapport à la technique pure. Maintenant que vous savez diagnostiquer et résoudre des pannes réseau et applicatives, nous allons voir comment ce travail s'intègre dans un cadre professionnel en abordant le rôle d'un système de gestion de tickets (helpdesk) et les bonnes pratiques de documentation d'incidents inspirées d'ITIL. Cela répond directement à votre intérêt pour les processus d'entreprise.