## Introduction Lorsqu'un serveur Linux de production se comporte mal, la différence entre une correction de 10 minutes et une panne de 10 heures tient souvent à une méthodologie de dépannage structurée. Ce guide s'adresse aux développeurs, ingénieurs DevOps et équipes techniques de startups qui doivent passer rapidement du symptôme à la cause racine, en toute sécurité. Nous couvrirons les domaines essentiels : collecte d'informations sur l'environnement, modifications de configuration sûres, exécution de diagnostics, gestion des modes de défaillance typiques et maintien d'une liste de contrôle opérationnelle. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les procédures de récupération. Chaque étape suit un schéma discipliné : - Identifier le composant et sa version. - Observer l'état actuel avec des commandes en lecture seule. - Définir le résultat attendu et le signal d'échec. - Modifier un seul élément ciblé uniquement lorsque c'est nécessaire. - Vérifier le résultat avec une commande concrète. - Documenter le chemin de récupération avant d'en avoir besoin. Nous utiliserons des espaces réservés explicites dans les commandes (comme votre_nom_de_service ) et n'inclurons jamais de véritables identifiants. ## Inventaire des versions et de l'environnement Avant de pouvoir corriger quoi que ce soit, vous devez savoir exactement ce que vous exécutez. Cette section vous aide à collecter les faits essentiels sur votre système. ### Identifier la distribution Linux et le noyau Commencez par les bases : quelle distribution et quel noyau utilisez-vous ? Les différentes distributions empaquètent les logiciels différemment et ont des configurations par défaut différentes. # Afficher les informations de distribution cat /etc/os-release Sortie attendue (extrait) : NAME="Ubuntu" VERSION="20.04.6 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.6 LTS" VERSION_ID="20.04" Vérifiez la version du noyau : uname -r Sortie attendue : 5.4.0-155-generic Notez ces valeurs car de nombreux guides et outils de dépannage ont des comportements spécifiques à la version. Par exemple, certains paramètres du noyau ou le comportement des appels système peuvent différer entre les versions du noyau. ### Vérifier les ressources système Un système lent est souvent un système à ressources limitées. Vérifiez la mémoire, le processeur et l'utilisation du disque. # Utilisation de la mémoire en mégaoctets free -m Sortie attendue (extrait) : total used free shared buff/cache available Mem: 7984 1234 4500 120 2250 6200 Swap: 2048 0 2048 Regardez la colonne available ; si elle est proche de zéro, le système est sous pression mémoire. # Charges moyennes du processeur uptime Sortie attendue : 14:23:45 up 21 days, 4:12, 2 users, load average: 0.85, 0.92, 1.10 Des charges moyennes supérieures au nombre de cœurs du processeur (vérifiez avec nproc ) indiquent une surcharge soutenue. # Utilisation du disque df -h Sortie attendue (extrait) : Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 55G 38G 60% / Un système de fichiers à 90 % ou plus nécessite une attention ; certains services échouent lorsque le disque est plein. ### Lister les services et ports clés Identifiez ce qui est censé fonctionner et s'il écoute sur les ports attendus. # Lister les services en cours d'exécution (sur systemd) systemctl list-units --type=service --state=running Trouver le statut d'un service spécifique : systemctl status nginx S'il ne fonctionne pas, démarrez-le et activez-le pour qu'il se lance au démarrage : sudo systemctl start nginx sudo systemctl enable nginx Vérifiez les ports en écoute : sudo ss -tulpn | grep nginx Sortie attendue : tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6)) tcp LISTEN 0 128 [::]:80 [::]:* users:(("nginx",pid=1234,fd=7)) Si un service devrait écouter mais ne le fait pas, vérifiez ses journaux et sa configuration. ## Chemin de configuration sûr Modifier des fichiers de configuration peut casser des choses si cela est fait sans précaution. Suivez un processus minutieux : sauvegardez, modifiez avec un contrôle de version, validez la syntaxe et rechargez progressivement. ### Sauvegarder les fichiers de configuration Faites toujours une sauvegarde horodatée avant de modifier un fichier de configuration. sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d) Vérifiez que la sauvegarde existe : ls -l /etc/nginx/nginx.conf.bak.* ### Modifier avec un contrôle de version Pour les configurations critiques, gardez-les sous contrôle de version. Si ce n'est pas déjà fait, initialisez un dépôt Git dans /etc (avec les permissions appropriées) et validez les modifications. cd /etc sudo git init sudo git add nginx/nginx.conf sudo git commit -m "Commit initial de la configuration nginx" Après modification, validez le changement : sudo git add nginx/nginx.conf sudo git commit -m "Mise à jour de worker_processes à 4" Cela vous permet de revenir facilement en arrière avec git checkout . ### Valider la syntaxe avant d'appliquer La plupart des démons fournissent une commande de vérification de syntaxe. Pour Nginx : sudo nginx -t Sortie attendue en cas de succès : nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Pour Apache : sudo apachectl configtest Pour le démon SSH : sudo sshd -t Si la vérification de syntaxe échoue, corrigez les erreurs avant de recharger ou de redémarrer. ### Recharger au lieu de redémarrer lorsque c'est possible Un rechargement applique les modifications de configuration sans interrompre les connexions existantes. Pour les services qui le prennent en charge (comme Nginx, Apache, HAProxy), utilisez reload : sudo systemctl reload nginx Vérifiez le statut du service après le rechargement : systemctl status nginx Si le service ne parvient pas à recharger, vérifiez les journaux et envisagez de revenir à la sauvegarde : sudo cp /etc/nginx/nginx.conf.bak.20250101 /etc/nginx/nginx.conf sudo systemctl reload nginx ## Vérification et diagnostics Après avoir effectué une modification ou lors du dépannage d'un problème, vous devez vérifier que le système se comporte comme prévu et collecter des informations de diagnostic. ### Consulter les journaux Les journaux sont le premier endroit où chercher les messages d'erreur. # Voir les 50 dernières lignes du journal système sudo journalctl -n 50 Pour un service spécifique : sudo journalctl -u nginx -n 50 --no-pager Suivre les journaux en temps réel : sudo journalctl -u nginx -f Les anciens fichiers syslog peuvent se trouver dans /var/log/ : sudo tail -n 50 /var/log/nginx/error.log ### Tester la connectivité réseau Utilisez curl pour tester un point de terminaison HTTP : curl -I http://localhost Sortie attendue en cas de succès : HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) Si vous voyez une connexion refusée ou un délai d'attente, le service n'écoute peut-être pas ou un pare-feu bloque. Vérifiez la résolution DNS : dig example.com Si dig n'est pas installé, installez dnsutils ou utilisez nslookup (obsolète) ou getent hosts example.com . ### Tester un service local avec Telnet ou Netcat Pour les services non HTTP, utilisez telnet ou nc pour vérifier si un port est ouvert et répond. # Tester le port SSH 22 nc -zv localhost 22 Sortie attendue : Connection to localhost 22 port [tcp/ssh] succeeded! ### Utiliser Strace pour les appels système Si un processus se bloque ou échoue mystérieusement, strace peut montrer les appels système qu'il effectue. sudo strace -p 1234 Remplacez 1234 par le PID du processus. Recherchez des erreurs comme ENOENT (fichier introuvable) ou EACCES (permission refusée). ## Modes de défaillance et récupération Les modes de défaillance courants ont des procédures de récupération standard. Nous couvrons ici le disque plein, le crash de service et la mauvaise configuration. ### Disque plein Un disque plein peut provoquer diverses pannes : services incapables d'écrire des journaux, bases de données refusant des écritures et instabilité du système. Symptômes : - df -h affiche Use% à 100 %. - Messages d'erreur comme « No space left on device » dans les journaux. - Services qui plantent ou deviennent insensibles. Étapes de récupération : - Identifier les fichiers ou répertoires volumineux : sudo du -ah / | sort -rh | head -n 20 - Vérifier les fichiers supprimés mais encore ouverts (courant avec la rotation des journaux) : sudo lsof +L1 - Nettoyer le cache des paquets : sudo apt clean - Supprimer les anciens fichiers journaux (mais tenir compte de la configuration de logrotate) : sudo find /var/log -type f -name "*.log" -mtime +30 -delete - Si possible, étendre le système de fichiers ou ajouter de l'espace disque. Vérification : df -h Assurez-vous que Use% est inférieur à 90 % et que les services critiques fonctionnent. ### Boucle de crash de service Un service qui ne cesse de planter peut être mal configuré ou atteindre une limite de ressources. Symptômes : - systemctl status votre_service affiche Active: activating (auto-restart) ou failed . - Messages d'erreur répétés dans les journaux. Étapes de récupération : - Consulter les journaux du service pour l'erreur exacte : sudo journalctl -u votre_service -n 100 --no-pager - Vérifier si le service tente de se lier à un port déjà utilisé : sudo ss -tulpn | grep votre_port - Vérifier les limites de ressources : ulimit -a - S'il s'agit d'une terminaison OOM (Out Of Memory), vérifier dmesg : dmesg | grep -i oom - Corriger la cause racine (par exemple, augmenter la limite de mémoire, corriger la configuration), puis démarrer le service : sudo systemctl start votre_service Vérification : systemctl status votre_service Devrait afficher Active: active (running) . ### Retour en arrière en cas de mauvaise configuration Si un changement de configuration récent a provoqué la panne, revenez à la version précédente. Si vous utilisez Git : cd /etc sudo git log --oneline -5 sudo git checkout -- nginx/nginx.conf sudo systemctl reload nginx Si vous utilisez des fichiers de sauvegarde : sudo cp /etc/nginx/nginx.conf.bak.20250101 /etc/nginx/nginx.conf sudo systemctl reload nginx Vérification : Vérifiez que le service fonctionne et que le comportement d'origine est restauré. ## Liste de contrôle des opérations Maintenez une liste de contrôle pour les vérifications de routine et le dépannage. Voici un tableau des éléments essentiels, du responsable et de la fréquence.
VérificationCommandeRésultat attenduResponsableFréquence
Utilisation du disquedf -hTous les systèmes de fichiers < 80 %Ingénieur DevOpsQuotidienne
Utilisation de la mémoirefree -mMémoire disponible > 20 %Ingénieur DevOpsQuotidienne
Charge CPUuptimeCharge < nombre de cœursIngénieur DevOpsQuotidienne
Statut du servicesystemctl status service-critiqueActif (en cours d'exécution)Administrateur systèmeHoraire (ou via surveillance)
Erreurs de journaljournalctl -p err --since todayAucune erreur inattendueIngénieur de gardeÀ chaque quart
Statut des sauvegardesVérifier les journaux de l'outil de sauvegardeSauvegardes réussiesAdministrateur de sauvegardeQuotidienne
Chaque élément doit avoir un responsable clair (pas un groupe) et une fréquence définie. Par exemple, l'ingénieur DevOps vérifie l'utilisation du disque quotidiennement ; l'ingénieur de garde examine les erreurs à chaque quart. ## Pièges courants et comment les éviter Même les ingénieurs expérimentés commettent des erreurs. Voici les pièges courants dans le dépannage Linux et comment les récupérer. ### 1. Faire des modifications sans sauvegarde Pourquoi cela arrive : Urgence, excès de confiance ou manque de discipline. Comment l'éviter : Créez toujours une sauvegarde horodatée avant de modifier. Utilisez des outils de gestion de configuration (Ansible, Puppet, Chef) pour maintenir des états connus et corrects. Récupération : Si vous avez oublié, vérifiez si le système dispose de sauvegardes automatiques (par exemple, des instantanés de /etc ). Sinon, reconstituez le fichier à partir de la documentation ou d'un modèle d'installation fraîche. ### 2. Exécuter des commandes avec des permissions incorrectes Pourquoi cela arrive : Essayer de lire ou d'écrire des fichiers en tant que mauvais utilisateur. Comment l'éviter : Utilisez sudo uniquement lorsque c'est nécessaire, et vérifiez les permissions des fichiers avec ls -l . Récupération : Si vous avez modifié les permissions de manière incorrecte, restaurez-les à partir de la sauvegarde ou utilisez chmod et chown pour définir les valeurs correctes (reportez-vous à la documentation). ### 3. Mal interpréter les messages de journal Pourquoi cela arrive : Les journaux peuvent être verbeux, et les messages d'erreur peuvent être trompeurs. Comment l'éviter : Apprenez à filtrer les journaux avec grep , les options de journalctl , et corrélez avec les horodatages. Comprenez le contexte : un avertissement peut être inoffensif, tandis qu'une erreur peut être fatale. Récupération : Si vous avez agi sur un journal mal interprété, vérifiez l'état réel du système avec d'autres commandes et revenez en arrière si nécessaire. ### 4. Ignorer les différences de version Pourquoi cela arrive : Copier des commandes à partir de sources en ligne sans vérifier si elles s'appliquent à votre distribution ou version. Comment l'éviter : Vérifiez toujours la version du système d'exploitation et du logiciel avant d'appliquer des commandes. Utilisez la documentation officielle pour votre version spécifique. Récupération : Si une commande a causé des problèmes en raison d'une incompatibilité de version, annulez la modification et consultez la documentation correcte. ## Conclusion Le dépannage Linux est une discipline systématique. En suivant les schémas décrits dans ce guide, vous pouvez réduire les temps d'arrêt et éviter des erreurs coûteuses. N'oubliez pas de : - Inventorier votre environnement avant d'apporter des modifications. - Utiliser des commandes en lecture seule pour observer. - Sauvegarder et valider les changements de configuration. - Vérifier les résultats avec des commandes concrètes. - Documenter les procédures de récupération. Comme prochaine étape, appliquez cette méthodologie à un composant à faible risque de votre environnement. Parcourez l'inventaire des versions et de l'environnement, identifiez une modification de configuration sûre et exercez-vous à la procédure de retour en arrière. Avec la répétition, ces habitudes deviennent une seconde nature, et vous serez bien préparé pour l'inévitable incident de production.