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 :

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

Astuce

Résistez à la tentation de changer la configuration au hasard. Diagnostiquez d'abord, corrigez ensuite. Modifier sans comprendre crée souvent un second problème.

Étape 1, Vérifier le service

Le service tourne-t-il ?

systemctl status est la première commande à taper parce qu'elle répond à deux questions d'un coup : l'état de l'unité, et les dernières lignes de journal associées. Sur la sortie, la ligne Active: porte l'information décisive, mais regardez aussi le Main PID: et le compteur de redémarrages : un identifiant de processus qui change à chaque exécution de la commande signale un service en boucle de redémarrage, ce qui oriente vers une erreur de configuration plutôt que vers un service simplement arrêté.

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)

Glissez pour voir

Lister tous les services en échec

Quand vous ne savez pas quel service incriminer, cette commande donne la liste complète des unités en état failed sur la machine, sans avoir à les interroger une par une. Elle est particulièrement utile après un redémarrage : un service qui échoue au boot n'affiche aucun message à l'écran, il se contente de passer en échec silencieusement.

systemctl --failed

Si un service que vous attendez apparaît ici, c'est votre piste principale. Une liste vide n'innocente pas systemd pour autant : un service configuré avec Restart=always qui replante en boucle repasse par l'état activating et peut ne pas apparaître ici au moment précis où vous lancez la commande.

Étape 2, Lire les logs

Les dernières lignes du service

-u nginx restreint le journal à cette unité, -n 30 n'affiche que les 30 dernières entrées. Trente lignes suffisent presque toujours, parce que la cause d'un échec de démarrage apparaît juste avant le message Failed to start. Lisez donc de bas en haut : la dernière ligne dit que le service a échoué, celle qui vous intéresse est deux ou trois lignes plus haut.

journalctl -u nginx -n 30

Les erreurs récentes sur tout le système

Cette commande sert quand le problème dépasse un seul service, typiquement un disque en erreur ou un manque de mémoire qui fait tomber plusieurs démons à la fois. -p err filtre sur la priorité syslog, et -b limite au démarrage en cours pour ne pas remonter des incidents d'il y a trois semaines.

journalctl -p err -b

Cela affiche uniquement les erreurs et les niveaux plus graves du boot actuel. Le filtrage -p fonctionne par seuil et non par égalité : -p err (priorité 3) sélectionne aussi crit, alert et emerg, dont les numéros sont inférieurs.

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

Ces cinq messages couvrent l'essentiel des échecs de démarrage rencontrés sur un serveur. Leur intérêt est qu'ils vous disent où chercher, pas quoi corriger. Address already in use renvoie vers ss -tlnp pour identifier le processus qui occupe déjà le port. Permission denied renvoie vers les droits du fichier concerné, mais aussi vers SELinux ou AppArmor sur une distribution qui les active : un fichier en 644 lisible par tous peut malgré tout être refusé si son contexte de sécurité est incorrect.

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

Glissez pour voir

Étape 3, Tester le réseau

La machine a-t-elle une connexion ?

On teste une adresse IP et non un nom de domaine, pour séparer deux pannes qui produisent le même symptôme : un défaut de routage et un défaut de résolution DNS. -c 4 arrête le ping après quatre paquets au lieu de le laisser tourner indéfiniment.

ping -c 4 8.8.8.8

Si ça fonctionne, la connectivité de base est bonne. Une absence de réponse ne prouve rien à elle seule : beaucoup de réseaux d'entreprise bloquent l'ICMP en sortie. Dans ce cas, testez plutôt l'ouverture d'une connexion TCP avec curl -sS -m 5 https://deb.debian.org avant de conclure à une panne réseau.

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 liste les sockets ouverts : -t pour le TCP, -l pour les sockets en écoute uniquement, -n pour garder les numéros de port au lieu de les traduire en noms de service, et -p pour afficher le processus propriétaire. Ce dernier n'affiche le nom du programme que si vous êtes root, sinon la colonne reste vide pour les processus des autres utilisateurs.

ss -tlnp | grep :80

Si aucun résultat, le service n'écoute pas sur ce port. Revenez à l'étape 1. Regardez aussi l'adresse d'écoute affichée à gauche du port : 127.0.0.1:80 signifie que le service n'accepte que les connexions locales, alors que 0.0.0.0:80 ou *:80 accepte celles venues du réseau. C'est une cause classique de « ça marche en local mais pas à distance », et elle se corrige dans la configuration du service, pas dans le pare-feu.

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)

sudo ufw status
sudo ufw allow 80/tcp

RHEL / Fedora (firewalld)

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

Résultat (extrait)

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.

Attention

Un disque plein est une cause fréquente et sournoise de pannes. Vérifiez-le systématiquement.

Mémoire

La colonne à ignorer sur cette sortie est free. Linux utilise systématiquement la mémoire inoccupée comme cache disque, comptabilisé dans buff/cache : une machine en bonne santé affiche donc presque toujours un free très bas, et ce n'est pas un signe de saturation. La colonne à lire est available, qui estime ce qu'une nouvelle application pourrait obtenir, cache récupérable compris.

free -h

Résultat

              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 rafraîchit sa liste toutes les trois secondes par défaut, ce qui permet de distinguer un processus durablement gourmand d'un pic passager. Un détail piège la lecture des pourcentages CPU : sur une machine à plusieurs cœurs, %CPU peut dépasser 100, une valeur de 400 signifiant qu'un processus occupe l'équivalent de quatre cœurs pleins.

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

Ces huit commandes se déroulent dans l'ordre, sans en sauter, même quand vous croyez connaître la cause. L'intérêt de cet enchaînement est qu'il élimine des hypothèses au lieu d'en confirmer une : après l'étape 4, si tout est vert, vous savez que la panne n'est ni un service arrêté, ni un port fermé, ni une ressource épuisée, ce qui recentre la recherche sur la configuration applicative ou sur un composant distant. Comptez deux minutes pour dérouler la totalité, moins que le temps généralement passé à chercher au hasard.

É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 ?

Glissez pour voir

Dépannage

Ce tableau associe les symptômes les plus fréquemment signalés par les utilisateurs aux vérifications correspondantes. Il se lit de gauche à droite : le symptôme est ce qu'on vous rapporte, la vérification est ce que vous tapez, la solution n'arrive qu'après. Attention à la ligne No space left on device, la commande journalctl --vacuum-time=3d supprime définitivement les journaux antérieurs à trois jours, ce qui peut effacer la trace de l'incident que vous cherchez à comprendre. Consultez les logs avant de purger.

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)

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À 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.

Pour aller plus loin

• 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.

×

📖 Voir la documentation →