Erreurs courantes sous Linux et correctifs : guide pratique de dépannage

Introduction

Les erreurs sous Linux sont inévitables, mais la manière dont vous y répondez détermine si un incident n'est qu'un bref contretemps ou une panne prolongée. Ce guide fournit aux développeurs, consultants DevOps et équipes techniques de startups une approche systématique pour diagnostiquer et corriger les problèmes Linux courants. Plutôt que des conseils épars, nous nous concentrons sur un flux de travail reproductible : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier chaque correctif et documenter les chemins de récupération.

Vous apprendrez à capturer l'état actuel, à identifier le comportement exact du composant, à appliquer le plus petit changement justifié et à confirmer le résultat avec des commandes concrètes et des sorties attendues. Chaque exemple inclut des considérations spécifiques à la version, des prérequis et un plan de retour en arrière testé.

Inventaire des versions et de l'environnement

Avant de toucher à quoi que ce soit, sachez exactement avec quoi vous travaillez. Une inadéquation entre vos hypothèses et l'environnement réel est la cause profonde de nombreux correctifs échoués.

Vérifiez la version du système d'exploitation et du noyau :

cat /etc/os-release
uname -r

Sortie attendue sur Ubuntu 22.04 :

VERSION_ID="22.04"
5.15.0-91-generic

Pour les systèmes basés sur Red Hat :

cat /etc/redhat-release

Exemple de sortie : Red Hat Enterprise Linux release 9.2 (Plow)

Listez les paquets installés pertinents pour votre problème. Par exemple, si vous déboguez une erreur réseau Docker, confirmez la version de Docker et le pilote de stockage :

docker version
sudo docker info | grep -E "Storage Driver|Server Version"

Exemple de sortie :

Server Version: 24.0.7
 Storage Driver: overlay2

Capturez les unités systemd en échec ou dégradées :

systemctl --failed --no-pager

La sortie montre les unités en échec, telles que :

  UNIT             LOAD   ACTIVE SUB    DESCRIPTION
● docker.service    loaded failed failed Docker Application Container Engine

Enregistrez toujours un horodatage avant d'apporter des modifications, afin de pouvoir corréler les entrées de journal :

date -u +"%Y-%m-%dT%H:%M:%SZ"

Note sur le rayon d'impact : Toutes les commandes de cette section sont en lecture seule. Elles ne modifient pas l'état du système et sont sûres à exécuter sur des systèmes de production.

Chemin de configuration sûr

Les erreurs de configuration sont parmi les pièges Linux les plus courants. La clé est de ne jamais modifier un fichier à l'aveugle. Sauvegardez toujours l'original, apportez une modification minimale, testez la syntaxe si disponible et sachez comment revenir en arrière.

1. Sauvegardez le fichier de configuration avec un horodatage :

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d%H%M%S)

2. Validez la syntaxe avant d'appliquer. Pour nginx :

sudo nginx -t

Succès attendu :

nginx: configuration file /etc/nginx/nginx.conf test is successful

Pour le démon SSH :

sudo sshd -t

Aucune sortie signifie que la syntaxe est valide.

3. Rechargez ou redémarrez le service avec une perturbation minimale. Préférez le rechargement lorsque cela est pris en charge :

sudo systemctl reload nginx

Si le rechargement échoue, vérifiez immédiatement l'état :

sudo systemctl status nginx --no-pager

4. Si le service échoue, revenez à la sauvegarde :

sudo cp /etc/nginx/nginx.conf.bak.20250219T143000 /etc/nginx/nginx.conf
sudo systemctl restart nginx

Exemple : Correction d'une mauvaise configuration courante du démon SSH. Supposons que SSH refuse l'authentification par mot de passe parce que PasswordAuthentication est réglé sur no par inadvertance. Vous modifiez /etc/ssh/sshd_config :

PasswordAuthentication yes

Puis validez et redémarrez :

sudo sshd -t && sudo systemctl restart sshd

Vérifiez que le paramètre a pris effet :

sudo sshd -T | grep -i passwordauthentication

Sortie attendue :

passwordauthentication yes

Note de sécurité : Ne mettez jamais de vrais mots de passe, jetons ou clés privées dans les exemples de configuration. Utilisez des espaces réservés clairement étiquetés comme VOTRE_SECRET_ICI dans la documentation, mais dans les fichiers réels, gérez les secrets avec un coffre-fort ou des variables d'environnement.

Vérification et diagnostics

Un correctif n'est pas complet tant que vous n'avez pas vérifié que le symptôme d'origine a disparu et que le système se comporte comme prévu. Cette section couvre les commandes de diagnostic essentielles pour les catégories d'erreurs Linux courantes.

Diagnostic des erreurs de système de fichiers et de disque

Vérifiez l'espace disque et l'utilisation des inodes :

df -h /var
sudo du -sh /var/log/* | sort -rh | head -5

Exemple de sortie :

2.1G    /var/log
1.1G    /var/log/syslog
...

Si les inodes sont épuisés, df -h peut montrer de l'espace disponible mais la création de fichiers échoue. Vérifiez les inodes :

df -i /var

Vérifiez la corruption du système de fichiers ou les erreurs au prochain démarrage. Utilisez fsck avec précaution, uniquement sur des partitions non montées :

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

La sortie attendue se termine par FILE SYSTEM CLEAN ou liste les corrections effectuées.

Diagnostic des problèmes de processus et de mémoire

Trouvez les processus consommant excessivement du CPU ou de la mémoire :

ps aux --sort=-%mem | head -10

Ou utilisez top de manière interactive. En mode batch :

top -bn1 | head -20

Vérifiez les processus zombies :

ps aux | awk '$8=="Z" {print}'

Si les zombies s'accumulent, trouvez leur parent et tuez-le :

ps -o ppid= -p <ZOMBIE_PID>

Diagnostic des erreurs réseau

Testez la connectivité et la résolution DNS :

ping -c 4 8.8.8.8
nslookup example.com

Si le ping échoue mais que le DNS résout, vérifiez le routage :

ip route show default

Vérifiez les ports en écoute et les processus qui les utilisent :

sudo ss -tulpn | grep LISTEN

Exemple de sortie :

tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=1123,fd=3))

Exemple : Débogage d'un code de sortie Docker 137

Le code de sortie 137 signifie souvent que le conteneur a été tué en raison d'un manque de mémoire (OOM) ou d'un signal d'arrêt. Vérifiez avec :

docker inspect --format='{{.State.ExitCode}} {{.State.OOMKilled}}' mycontainer

Attendu : 137 true si OOM, 137 false si arrêté de l'extérieur. Consultez les journaux système pour les messages du tueur OOM :

sudo journalctl -k | grep -i oom

Exemple de sortie :

kernel: Out of memory: Killed process 2312 (node) total-vm:1234567kB, anon-rss:900000kB

Comparez toujours la sortie observée à la sortie attendue. Documentez le signal attendu avant d'exécuter les diagnostics.

Modes de défaillance et récupération

Anticipez ce qui peut mal tourner et ayez un plan de récupération prêt avant d'apporter un changement. Cette section couvre les modes de défaillance courants et des exemples de récupération étape par étape.

Défaillance : Le service systemd ne démarre pas

Symptôme : systemctl start myservice renvoie un code d'erreur, et systemctl status affiche failed.

Diagnostic :

sudo journalctl -u myservice.service -n 50 --no-pager

Cherchez la cause profonde. Par exemple, s'il indique Executable path is not absolute, le fichier d'unité utilise un chemin relatif.

Correctif : Modifiez le fichier d'unité (par exemple, /etc/systemd/system/myservice.service) et définissez un ExecStart absolu :

ExecStart=/usr/local/bin/myservice --config /etc/myservice/config.yaml

Rechargez systemd et redémarrez :

sudo systemctl daemon-reload
sudo systemctl start myservice

Vérification :

sudo systemctl is-active myservice

Attendu : active.

Retour en arrière : Si le service échoue toujours, revenez au fichier d'unité de sauvegarde ou réinstallez le paquet.

Défaillance : Disque plein en raison de journaux pivotés

Symptôme : Les écritures de l'application échouent avec No space left on device, mais df -h montre de l'espace disponible.

Diagnostic : Vérifiez les descripteurs de fichiers supprimés mais toujours ouverts :

sudo lsof +L1 | grep deleted

La sortie montre les processus détenant des fichiers supprimés. Par exemple :

nginx     1234  www-data   12u   REG  253,0  1048576  917504  /var/log/nginx/access.log (deleted)

Correctif : Rechargez ou redémarrez gracieusement le processus qui détient le descripteur :

sudo systemctl reload nginx

L'espace sera récupéré. Confirmez :

df -h /

Prévention : Utilisez la rotation des journaux avec copytruncate ou envoyez les journaux à un syslog central.

Défaillance : Résolution DNS intermittente

Symptôme : Certaines commandes échouent avec Temporary failure in name resolution, tandis que d'autres réussissent.

Diagnostic : Vérifiez /etc/resolv.conf et l'état de systemd-resolved :

cat /etc/resolv.conf
sudo systemctl status systemd-resolved --no-pager

Si vous utilisez NetworkManager, vérifiez les paramètres DNS de la connexion :

nmcli device show eth0 | grep IP4.DNS

Correctif : Corrigez l'ordre des serveurs DNS ou ajoutez un serveur de secours. Par exemple, modifiez /etc/netplan/01-netcfg.yaml (Ubuntu 20.04+) :

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Appliquez avec :

sudo netplan apply

Vérification :

resolvectl status

Ou testez avec une commande dig.

Retour en arrière : Restaurez le fichier netplan d'origine ou reconfigurez via DHCP le cas échéant.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après tout changement dans un environnement de type production. Adaptez-la à votre composant spécifique, mais assurez-vous que chaque élément est traité.

Liste de contrôle pré-changement

• [ ] Identifiez le composant exact et sa version (par exemple, nginx -v, php -v).
• [ ] Capturez l'état actuel avec des commandes en lecture seule et enregistrez la sortie dans un fichier texte.
• [ ] Enregistrez l'heure actuelle (UTC) pour corréler les journaux.
• [ ] Identifiez le résultat attendu et le signal d'échec.
• [ ] Préparez le plus petit changement possible avec un plan de retour en arrière clair.
• [ ] Confirmez que vous disposez de privilèges suffisants (sudo -l) et que vous êtes sur le bon hôte (hostname).
• [ ] Si vous modifiez la configuration, sauvegardez le fichier original avec un suffixe d'horodatage.

Liste de contrôle de vérification post-changement

• [ ] Exécutez la vérification de syntaxe du service si disponible (par exemple, nginx -t, sshd -t).
• [ ] Rechargez ou redémarrez le service en utilisant la méthode la moins perturbatrice.
• [ ] Vérifiez l'état du service : systemctl is-active <service>.
• [ ] Vérifiez que le symptôme d'origine a disparu : exécutez la commande qui échouait à l'origine et comparez la sortie.
• [ ] Consultez les derniers journaux pour les erreurs : journalctl -u <service> -n 50 --no-pager.
• [ ] Surveillez pendant quelques minutes pour assurer la stabilité (par exemple, watch -n 2 systemctl status <service>).
• [ ] Documentez le changement et son résultat dans votre journal d'incidents ou votre système de gestion des changements.

Exemple concret : Application de la liste de contrôle à la mise à jour d'un certificat TLS de serveur Web

Supposons que vous deviez mettre à jour un certificat TLS expiré pour nginx.

Pré-changement :

• Confirmez la version de nginx : nginx -v → nginx/1.22.1.
• Vérifiez l'expiration du certificat actuel : echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates.
• Sauvegardez l'ancien certificat et la clé : sudo cp /etc/ssl/certs/example.com.crt /etc/ssl/certs/example.com.crt.old et de même pour la clé.
• Placez les nouveaux fichiers de certificat et de clé, puis exécutez sudo nginx -t → attendez syntax is ok.

Post-changement :

• Rechargez nginx : sudo systemctl reload nginx.
• Vérifiez l'état : systemctl is-active nginx → active.
• Vérifiez la nouvelle expiration : echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate.
• Consultez les journaux : tail -f /var/log/nginx/error.log pour toute erreur TLS.
• Mettez à jour la documentation : enregistrez la nouvelle date d'expiration et les emplacements des fichiers.

Conclusion

Maîtriser les erreurs courantes sous Linux consiste moins à mémoriser des correctifs qu'à adopter un flux de travail discipliné. Commencez par un inventaire précis des versions et de l'environnement, capturez l'état observable avant de toucher à quoi que ce soit, apportez des modifications minimales et réversibles, et vérifiez toujours le résultat par rapport à un signal attendu prédéfini. Utilisez des espaces réservés dans la documentation et gardez les vrais secrets hors des exemples de commandes et des fichiers journaux.

Choisissez une vérification à faible risque de ce guide et appliquez-la aujourd'hui. Par exemple, exécutez systemctl --failed pour voir si des services sont actuellement en état d'échec, ou consultez les journaux de votre service le plus critique avec journalctl -u <service> -n 50. Enregistrez ce que vous trouvez, comparez-le aux attentes et décidez d'une prochaine étape. Au fil du temps, cette pratique construit une mémoire musculaire opérationnelle robuste, transformant les erreurs de crises en points de contrôle gérables.

N'oubliez pas de passer en revue les dépendances telles que systemd, Bash et Docker uniquement lorsqu'elles affectent directement votre problème. Gardez vos chemins de récupération documentés avant qu'un incident ne force une décision. Avec de la diligence et les bons outils, vous pouvez garder vos systèmes Linux sains et résilients.