Vous êtes en incident : un service est tombé, le serveur ne répond plus, ou le disque est saturé. Cette page est une table d'orientation. Vous y trouvez votre symptôme, la première commande à taper pour le qualifier, et le guide qui traite la panne en entier. Personne ne lit une formation pendant une panne : on cherche son symptôme, on veut la commande, et on veut savoir si on a réparé.
Ce module s'adresse à l'administrateur qui doit rétablir un service en production, et à celui qui prépare les scénarios de dépannage de la RHCSA et de la LFCS, où le diagnostic est chronométré.
Trouver son symptôme
Section intitulée « Trouver son symptôme »Chaque ligne du tableau part de ce que vous observez, pas de la technologie en cause. Deux lignes portent le même message, « Permission denied », et c'est volontaire : c'est le seul symptôme de la liste qui se qualifie en deux temps. Les droits Unix et les ACL se lisent d'abord ; si les deux sont bons et que l'accès reste refusé, la cause est le contrôle d'accès obligatoire, SELinux sur RHEL, AppArmor sur Ubuntu. La deuxième colonne est la commande qui qualifie le symptôme, c'est-à-dire celle qui transforme une plainte vague en fait vérifiable. Tant que vous n'avez pas cette réponse, toute correction est une supposition.
| Ce que vous observez | La commande qui qualifie | La procédure |
|---|---|---|
Le service refuse de démarrer, systemctl le dit failed | systemctl status <service> | Un service ne démarre pas |
Le service est active (running) mais ne répond plus | curl -m 5 puis ps -o stat | Un service actif qui ne répond pas |
| Vous n'arrivez plus à vous connecter en SSH | Lire le message exact du client | Retrouver l'accès SSH |
| Le serveur est injoignable, ou un port ne répond pas | ip addr puis ss -tlnp | Diagnostiquer un problème réseau |
| Les écritures échouent, « No space left on device » | df -h puis df -i | Espace disque et inodes |
| Le serveur est lent, sans raison évidente | uptime puis vmstat 1 | Évaluer les performances |
| La charge moyenne grimpe et ne redescend pas | uptime, top | Vérifier la charge système |
| Un processus est tué sans explication | journalctl -k | grep -i oom | Surveiller la mémoire |
| La machine ne termine pas son démarrage | Console, puis journalctl -b -p err | Un serveur bloqué au démarrage |
| « Permission denied » sur un fichier | ls -l puis getfacl | Permissions et ACL |
| « Permission denied » alors que droits et ACL sont bons | ausearch -m avc -ts recent sur RHEL, aa-status sur Ubuntu | SELinux ou AppArmor |
| Un montage a disparu après un redémarrage | findmnt et /etc/fstab | Monter et rendre persistant |
| Le système de fichiers refuse les écritures | touch : lire le message exact | Un système de fichiers en lecture seule |
La méthode passe avant les commandes
Section intitulée « La méthode passe avant les commandes »Un dépanneur pressé teste des correctifs au hasard et finit par casser autre chose. La discipline qui fait la différence tient en une phrase : observer, formuler une hypothèse, la tester par une seule modification, vérifier, et seulement ensuite passer à la suivante. Sans cette méthode, vous ne savez plus ce qui a réparé la panne, donc vous ne saurez pas la reproduire ni l'éviter.
Les trois sources qui parlent toujours
Section intitulée « Les trois sources qui parlent toujours »Quel que soit le symptôme, trois sources de vérité répondent en premier. Le journal systemd dit ce que le système a tenté et pourquoi il a renoncé. Les processus disent qui consomme et qui est bloqué. Les sockets disent qui écoute vraiment sur le port que vous croyez ouvert. Un diagnostic qui n'a consulté aucune des trois est un diagnostic qui devine.
Ce que vous saurez faire
Section intitulée « Ce que vous saurez faire »Le dépannage n'est pas une collection de commandes, c'est une capacité observable : ramener un service en état de marche et prouver qu'il l'est. Au terme de ce module, vous savez :
- Qualifier un incident : transformer « ça ne marche plus » en un fait vérifiable, avec une commande et sa sortie.
- Lire un journal systemd et y reconnaître la ligne qui compte, pas les cinquante lignes de bruit qui l'entourent.
- Isoler la couche fautive : réseau, service, configuration, stockage ou noyau, sans toucher aux quatre autres.
- Vérifier la réparation, y compris après un redémarrage, parce qu'un service réparé qui ne survit pas au reboot n'est pas réparé.
Mettre en pratique
Section intitulée « Mettre en pratique »La méthode ci-dessus ne vaut que si elle tient face à une panne qu'on n'a pas choisie. Le lab en tire une au sort parmi six et ne dit jamais laquelle : service arrêté, mauvais port, pare-feu fermé, contexte SELinux, permissions du docroot, système de fichiers plein. Vous diagnostiquez, vous réparez, et la réparation doit survivre au redémarrage. Trois contrôles refusent au passage les réparations à la masse : SELinux reste enforcing, firewalld reste actif, et le docroot ne devient jamais accessible en écriture à tous.
À retenir
Section intitulée « À retenir »- Le symptôme est la porte d'entrée, pas la technologie. On part de ce que l'utilisateur observe, on remonte vers la cause.
- Qualifier avant de corriger : une commande qui transforme la plainte en fait, sinon vous réparez une panne imaginaire.
- Une modification à la fois, sinon vous ne saurez jamais laquelle a réparé.
- Trois sources répondent toujours : le journal systemd, les processus, les sockets en écoute.
- Réparer et prouver sont deux gestes distincts, et la preuve inclut le passage du redémarrage.