Dépannage Linux avec exemples pratiques : guide de terrain pour DevOps

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é :

1. Identifier le composant et sa version.
2. Observer l'état actuel avec des commandes en lecture seule.
3. Définir le résultat attendu et le signal d'échec.
4. Modifier un seul élément ciblé uniquement lorsque c'est nécessaire.
5. Vérifier le résultat avec une commande concrète.
6. 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 :

1. Identifier les fichiers ou répertoires volumineux :

sudo du -ah / | sort -rh | head -n 20

1. Vérifier les fichiers supprimés mais encore ouverts (courant avec la rotation des journaux) :

sudo lsof +L1

1. Nettoyer le cache des paquets :

sudo apt clean

1. Supprimer les anciens fichiers journaux (mais tenir compte de la configuration de logrotate) :

sudo find /var/log -type f -name "*.log" -mtime +30 -delete

1. 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 :

1. Consulter les journaux du service pour l'erreur exacte :

sudo journalctl -u votre_service -n 100 --no-pager

1. Vérifier si le service tente de se lier à un port déjà utilisé :

sudo ss -tulpn | grep votre_port

1. Vérifier les limites de ressources :

ulimit -a

1. S'il s'agit d'une terminaison OOM (Out Of Memory), vérifier dmesg :

dmesg | grep -i oom

1. 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 <hash_commit> -- 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.

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.