Premiers gestes de dépannage Linux

Face à un problème Linux, la méthode est toujours la même : vérifier le service, lire les logs, tester le réseau, contrôler les ressources. Ces quatre étapes résolvent la grande majorité des incidents. Ce guide vous donne les réflexes essentiels pour diagnostiquer un problème de manière structurée.

Ce que vous allez apprendre

Appliquer une méthode de diagnostic en 4 étapes
Vérifier l’état d’un service avec systemctl et lire ses logs
Diagnostiquer un problème réseau de base
Identifier un manque d’espace disque ou de mémoire
Adopter les bons réflexes face à un incident

La méthode en 4 étapes

Quand quelque chose ne fonctionne pas, suivez toujours cet ordre :

Vérifier le service : est-il démarré ? a-t-il planté ?
Lire les logs : que disent les journaux ?
Tester le réseau : la machine est-elle joignable ? le port écoute-t-il ?
Contrôler les ressources : reste-t-il de l’espace disque et de la mémoire ?

Étape 1 — Vérifier le service

Le service tourne-t-il ?

systemctl status nginx

Trois résultats possibles :

État	Signification	Action
`active (running)`	Le service fonctionne	Problème ailleurs (réseau, config…)
`inactive (dead)`	Le service est arrêté	Le démarrer : `sudo systemctl start nginx`
`failed`	Le service a planté	Lire les logs (étape 2)

Lister tous les services en échec

systemctl --failed

Si un service que vous attendez apparaît ici, c’est votre piste principale.

Étape 2 — Lire les logs

Les dernières lignes du service

journalctl -u nginx -n 30

Les erreurs récentes sur tout le système

journalctl -p err -b

Cela affiche uniquement les erreurs (et plus grave) du boot actuel.

Suivre les logs en direct

Ouvrez un terminal dédié pendant que vous tentez un redémarrage :

journalctl -u nginx -f

Puis dans un autre terminal :

sudo systemctl restart nginx

Vous verrez le message d’erreur apparaître en direct.

Exemples de messages courants

Message dans les logs	Signification
`Address already in use`	Le port est déjà occupé par un autre processus
`Permission denied`	Le service n’a pas les droits nécessaires
`No such file or directory`	Un fichier de configuration ou un binaire manque
`Failed to parse`	Erreur de syntaxe dans la configuration
`Connection refused`	Le service distant n’écoute pas

Étape 3 — Tester le réseau

La machine a-t-elle une connexion ?

ping -c 4 8.8.8.8

Si ça fonctionne, la connectivité de base est bonne.

Le DNS fonctionne-t-il ?

ping -c 4 google.com

Si ping 8.8.8.8 passe mais pas ping google.com, le problème est DNS. Vérifiez /etc/resolv.conf.

Le port du service écoute-t-il ?

ss -tlnp | grep :80

Si aucun résultat, le service n’écoute pas sur ce port. Revenez à l’étape 1.

Depuis une autre machine, le port est-il accessible ?

curl -I http://192.168.1.10

Si le service écoute localement (ss le confirme) mais n’est pas joignable depuis l’extérieur, un pare-feu bloque probablement le trafic.

Debian / Ubuntu (ufw)
RHEL / Fedora (firewalld)

sudo ufw status
sudo ufw allow 80/tcp

sudo firewall-cmd --list-all
sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --reload

Étape 4 — Contrôler les ressources

Espace disque

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   47G  3.0G  94% /

Un système de fichiers à 100% empêche l’écriture de logs, de fichiers temporaires et peut bloquer des services.

Mémoire

free -h

              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       2.1Gi       200Mi       50Mi       1.5Gi       1.4Gi
Swap:         2.0Gi       500Mi       1.5Gi

available indique la mémoire réellement disponible pour les applications.
Si available est proche de zéro et le swap très utilisé, la machine manque de RAM.

Les processus qui consomment le plus

top

Dans top, appuyez sur M pour trier par mémoire, ou P pour trier par CPU. Appuyez sur q pour quitter.

Récapitulatif : la checklist de dépannage

Étape	Commande	Ce que vous vérifiez
1	`systemctl status service`	Le service est-il actif ?
1	`systemctl --failed`	Y a-t-il des services en échec ?
2	`journalctl -u service -n 30`	Que disent les logs du service ?
2	`journalctl -p err -b`	Y a-t-il des erreurs système ?
3	`ping -c 4 8.8.8.8`	La connectivité réseau fonctionne ?
3	`ss -tlnp \| grep :port`	Le port du service est-il ouvert ?
4	`df -h`	Le disque est-il plein ?
4	`free -h`	La mémoire est-elle suffisante ?

Dépannage

Symptôme	Vérification	Solution
Le site web ne répond pas	`systemctl status nginx` + `ss -tlnp \| grep :80`	Redémarrer le service ou débloquer le port dans le pare-feu
Impossible de se connecter en SSH	`systemctl status sshd` + `ss -tlnp \| grep :22`	Démarrer sshd et vérifier le pare-feu
Le serveur est très lent	`top` + `free -h` + `df -h`	Identifier le processus gourmand, libérer de l’espace disque
Un service redémarre en boucle	`journalctl -u service -f`	Lire le message d’erreur et corriger la configuration
Erreur « No space left on device »	`df -h`	Supprimer des fichiers ou des vieux logs : `sudo journalctl --vacuum-time=3d`
Le réseau fonctionne en IP mais pas en nom	`cat /etc/resolv.conf`	Ajouter un serveur DNS valide (ex : `nameserver 8.8.8.8`)

À retenir

Toujours suivre l’ordre : service → logs → réseau → ressources.
systemctl status et journalctl -u forment le duo de base du diagnostic.
Testez le réseau d’abord en IP, puis en nom de domaine pour isoler un problème DNS.
Un disque plein est une cause fréquente et parfois invisible de pannes.
Ne modifiez rien avant d’avoir identifié la cause : diagnostiquez d’abord, corrigez ensuite.

Prochaines étapes

Méthode de diagnostic avancée Approfondir le diagnostic par symptômes avec une méthodologie structurée.

Diagnostiquer un problème réseau Dépanner la connectivité réseau avec une approche systématique.

Comprendre systemd en profondeur Maîtriser les units, timers et le durcissement de services.