Lorsqu’un serveur Linux cesse de répondre, la tentation est souvent d’accéder via SSH et de commencer à exécuter des commandes telles que top, free, df, systemctl, journalctl. Bien qu’elles soient utiles, ces actions ne devraient pas toujours être la première étape. Avant de diagnostiquer CPU, mémoire ou disque, il est judicieux de répondre à une question plus fondamentale : le serveur est-il réellement hors service ou simplement inaccessible par une route spécifique ?

C’est pourquoi, dans une situation réelle, la première commande ne sera généralement pas effectuée directement sur le serveur. Il s’agit souvent d’une étape aussi simple que :

ping -c 4 

Ou, si vous souhaitez un peu plus d’informations sur la route :

mtr 

La raison en est simple : en l’absence de connectivité, tout le reste change. Il est possible que le système d’exploitation fonctionne, mais qu’il y ait un problème réseau, configuration de pare-feu, routage, commutateur, VPN, équilibrage de charge, fournisseur cloud ou règle de sécurité. Si l’on commence directement par SSH et que celui-ci ne répond pas, on pourrait tirer une conclusion erronée : « le serveur est mort ». Parfois, ce n’est pas le cas. Le serveur est simplement isolé.

Un bon diagnostic système commence par différencier les symptômes. Ce n’est pas la même chose qu’un site web qui ne charge pas, un port 22 qui ne répond pas, l’absence d’ICMP, un serveur gelé, un noyau encore en vie mais sans processus utiles, ou un disque saturé à 100 % empêchant l’écriture de logs.

Première étape : vérifier si on peut joindre la machine

La première minute d’une incident devrait servir à confirmer la portée. Un serveur ou plusieurs ? Un seul service ou toute la machine ? Depuis une localisation spécifique ou depuis n’importe quel réseau ? Y a-t-il des utilisateurs affectés ou seulement une surveillance précise ?

Une démarche logique commence par la connectivité :

ping -c 4 

Ensuite, vérifier le routage :

mtr 

Et si le serveur répond à la requête réseau, tester le service affecté :

curl -I https://domaine.com
nc -vz  22
nc -vz  443

Cela permet d’identifier si le problème se situe au niveau du réseau, du port, du service ou d’une couche intermédiaire. Si ping répond mais que SSH non, le serveur n’est pas nécessairement hors service. Il peut y avoir un problème avec sshd, pare-feu, saturation de processus, limites de connexion ou charge excessive empêchant l’ouverture de session.

Si aucune réponse n’est reçue, le prochain réflexe ne doit pas être de redémarrer à l’aveugle. Il faut utiliser une console alternative via KVM, iLO, iDRAC, IPMI, console de l’hyperviseur, console du fournisseur cloud ou accès série si disponible. Redémarrer peut restaurer le service, mais aussi supprimer des preuves essentielles, transformant un diagnostic possible en une anecdote sans cause racine.

Si SSH répond, le premier ordre utile est uptime

Une fois à l’intérieur du serveur, la première commande offrant une vue rapide est :

uptime

Elle ne règle pas le problème, mais oriente. Elle indique depuis combien de temps le serveur est en fonctionnement, combien d’utilisateurs y sont connectés et surtout, la charge moyenne. Si le load average est élevé, c’est une piste. Si une machine avec 4 vCPU affiche des charges de 80, 120 ou 300, le système peut être opérationnel mais quasiment inutilisable.

Ensuite, il est pertinent d’observer les processus :

top -b -n 1 | head -20

Ou une vue plus directe par CPU :

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

Et par mémoire :

free -h
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

Ce diagnostic permet de distinguer si le problème provient du CPU, de la RAM, du swap, de processus en boucle, de fuites mémoire ou d’un excès de tâches bloquées.

Un point crucial : si de nombreux processus sont en état D, cela peut indiquer un problème de disque ou de stockage, et pas nécessairement un problème de CPU. Le serveur peut sembler gelé parce qu’il attend des opérations d’I/O qui ne se terminent pas. Mieux vaut évaluer avant de tuer des processus, sous peine de compliquer la situation.

Disque, inodes et logs : trois éléments classiques à surveiller

Beaucoup d’incidents Linux classiques ont des causes simples : disque plein, répertoire de logs hors de contrôle, sauvegarde mal planifiée, application écrivant des millions de petits fichiers, partition /var saturée à 100 %, volume sans inodes alors qu’il reste de l’espace en GB.

Voici donc trois commandes essentielles à avoir à portée :

df -h
df -i
du -xhd 1 / 2>/dev/null | sort -hr | head

df -h affiche l’espace disque utilisé et disponible. df -i montre l’utilisation des inodes, souvent oubliée. Si les inodes sont épuisés, le système ne pourra pas créer de nouveaux fichiers, même si l’espace disque semble suffisant.

Les journaux récents sont également cruciaux :

journalctl -xe --no-pager | tail -50
journalctl -p err --since "1 hour ago"
dmesg -T | tail -100

Ils révèlent d’éventuelles erreurs du noyau, bogues disque, OOM Killer, services qui redémarrent en boucle, problèmes réseau ou messages d’I/O. Avant de procéder à un redémarrage, il est recommandé de vérifier, car celui-ci peut effacer le contexte temporaire expliquant la panne.

Mitiger n’est pas diagnostiquer

Lors d’un incident, deux objectifs sont souvent en conflit : rétablir le service et comprendre la cause. L’équilibre dépend de la gravité de l’incident. En cas de panne majeure, la mitigation doit être rapide, mais sans supprimer toutes les preuves.

Voici quelques actions courantes :

Une commande potentiellement nécessaire est :

kill -9 

Mais cela doit être une décision, pas une réaction impulsive. kill -9 empêche le processus de se fermer proprement. Parfois, c’est inévitable ; d’autres fois, il suffit de redémarrer un service ou d’interrompre une file de tâches.

La même logique s’applique au redémarrage du serveur :

systemctl reboot --force

Celui-ci doit être un dernier recours. Si le système est complètement figé et qu’aucun autre moyen n’est possible, on peut utiliser la console ou le SysRq, mais en sachant ce qu’on fait. La récupération rapide ne doit pas entraîner une perte de données ou un dommage supplémentaire non justifié.

L’incident ne s’arrête pas au retour du service

L’une des erreurs les plus coûteuses en opération consiste à clôturer l’incident dès que le site répond à nouveau. C’est la fin de la chute, mais pas du travail. Il est essentiel de documenter ce qui s’est passé, la durée, l’impact, les actions menées, ce qui a fonctionné et ce qui doit changer pour éviter qu’un incident similaire se reproduise.

Une analyse post-incident efficace devrait répondre à ces questions essentielles :

Le principe essentiel est simple : ne pas deviner. Observer, mesurer et comprendre avant d’agir. Un bon administrateur systèmes n’est pas celui qui tape le plus de commandes, mais celui qui sait dans quel ordre les exécuter et quand arrêter avant d’aggraver la situation.

En résumé, si une réponse courte doit être donnée à la question initiale : je vérifie d’abord la connectivité avec ping ou mtr; si SSH répond, je lance uptime. La première étape sépare réseau du système. La seconde donne une lecture rapide de la charge et de l’état général. Ensuite, le diagnostic n’est plus effectué à l’aveugle.

Questions fréquentes

Quel est le premier commandement face à un serveur qui ne répond pas ?
De l’extérieur, utiliser ping -c 4 ou mtr pour vérifier la connectivité. Si SSH répond, à l’intérieur du serveur, la première commande utile est généralement uptime.

Pourquoi ne pas commencer directement par top ?
Parce qu’on n’a peut-être pas encore d’accès réel au serveur. La priorité est de déterminer si le problème vient du réseau, de l’accès, du port, du service ou du système global.

Quelle commande permet de détecter un disque saturé ?
df -h pour l’espace disque et df -i pour l’utilisation des inodes. Les deux sont importants puisque le système peut atteindre la limite d’inodes même s’il reste de la place en GB.

Quels journaux consulter dans les premières minutes ?
journalctl -xe --no-pager, journalctl -p err --since "1 hour ago" et dmesg -T | tail -100 donnent rapidement des indications sur les erreurs récentes.

Quand faut-il redémarrer un serveur ?
Lorsque la mitigation la moins invasive a été tentée et que le système est irrécupérable. Le redémarrage sans diagnostic peut supprimer des preuves importantes et masquer la cause profonde.