Dépanner un serveur Linux : méthode et cas types

Dépanner un serveur Linux, c'est passer d'un symptôme (« le site ne répond plus », « le serveur ne démarre pas ») à sa cause, par des vérifications ordonnées plutôt que par des essais au hasard, puis corriger, vérifier et documenter. Ce chapitre donne la méthode, la chaîne de démarrage et les points où elle casse, les pannes les plus fréquentes avec leurs commandes, puis deux cas complets au format des épreuves E6 et E7 de l'option SISR.

La méthode

1. Décrire le symptôme précisément : qui est touché, depuis quand, quel message exact. « Le site ne marche pas » devient « depuis 9 h 10, les clients reçoivent une erreur 502 sur suivi.sorbier.example ; le site interne de srv-gestion répond normalement ».
2. Délimiter : une machine ou toutes ? Un service ou tout le serveur ? Ce qui a changé récemment (mise à jour, modification de configuration, ajout de disque) est le premier suspect : /var/log/apt/history.log, journalctl --since.
3. Observer avant d'agir : état des services, journaux, espace disque, réseau. On lit les messages d'erreur en entier : ils donnent la cause une fois sur deux.
4. Formuler une hypothèse et la tester, une seule à la fois, sans tout modifier d'un coup.
5. Corriger, en gardant une copie de ce qu'on change.
6. Vérifier que le symptôme a disparu, pour les utilisateurs, pas seulement dans ton terminal.
7. Documenter dans le ticket : symptôme, cause, correction, et ce qui évitera que ça recommence (une alerte de supervision, une procédure). L'outil de tickets et la démarche ITIL sont présentés dans les cours GLPI et gestion de parc et ITIL et support.

La chaîne de démarrage

Quand un serveur ne démarre plus, il faut savoir à quelle étape il s'arrête. Chacune affiche des messages reconnaissables :

Un serveur qui ne démarre plus

Le mode d'urgence. Après l'ajout d'un disque, srv-journaux s'arrête sur « You are in emergency mode. After logging in, type "journalctl -xb" to view system logs ». La cause habituelle : une ligne de /etc/fstab qui désigne un disque absent ou un UUID mal recopié. La réparation :

1. donner le mot de passe de root si on te le demande (voir l'encadré pour le cas où root est verrouillé) ;
2. journalctl -xb | grep -i -A3 mount : le message nomme le montage en échec ;
3. mount -o remount,rw / si la racine est en lecture seule, puis corriger /etc/fstab (UUID exact avec blkid, ou nofail, ou ligne commentée) ;
4. systemctl daemon-reload && mount -a, puis systemctl default (ou reboot).

Démarrer en mode de secours. Dans le menu de GRUB, place-toi sur l'entrée Debian et appuie sur e. À la fin de la ligne qui commence par linux, ajoute systemd.unit=rescue.target (ou emergency.target pour le minimum), puis Ctrl+X pour démarrer. La modification ne vaut que pour ce démarrage.

Les pannes fréquentes

Un disque plein. Symptômes : services qui s'arrêtent, « No space left on device », base de données en lecture seule.

df -h                                         # quel système de fichiers est plein ?
df -i                                         # ou n'a plus d'inodes ?
sudo du -xh --max-depth=1 /var | sort -h      # où est la place, dossier par dossier
sudo journalctl --vacuum-size=500M            # si c'est le journal
sudo apt clean                                # si c'est le cache des paquets
sudo lsof +L1                                 # fichiers supprimés mais encore ouverts (paquet lsof)

Le dernier cas est classique : un journal supprimé à la main par rm alors qu'un service l'a encore ouvert continue d'occuper le disque, invisible pour du. Redémarrer le service libère la place. Pour une solution durable : logrotate, un volume dédié, une alerte de supervision à 80 %.

Un service qui ne démarre pas.

systemctl status nginx                        # état et dernières lignes
journalctl -xeu nginx                         # le journal du service, avec explications
sudo nginx -t                                 # syntaxe de la configuration (sshd -t, named-checkconf…)
sudo ss -tlnp | grep ':443'                   # le port est-il déjà pris par un autre programme ?
namei -l /srv/www/suivi/index.html            # les droits sur tout le chemin
sudo journalctl -k -g 'apparmor="DENIED"'     # un refus d'AppArmor ?

Le réseau. Remonter les couches dans l'ordre du chapitre 11 : lien, adresse, passerelle, route, DNS, port.

Une machine lente. uptime (charge comparée au nombre de cœurs), top trié par processeur (P) puis par mémoire (M), free -h (le swap est-il plein ?), dmesg -T | tail ou journalctl -k -p warning (erreurs de disque, manque de mémoire : « Out of memory: Killed process »). iostat -x 2 (paquet sysstat) montre si un disque sature.

« Permission non accordée ». id (quels groupes, et la session a-t-elle été rouverte depuis l'ajout ?), ls -l et getfacl sur le fichier, namei -l sur le chemin, sudo -l pour les droits sudo, puis le journal d'AppArmor.

L'heure. Certificats refusés, connexions Kerberos impossibles, journaux incohérents : timedatectl doit afficher le bon fuseau (Europe/Paris) et System clock synchronized: yes.

Cas type E6 SISR : une demande d'évolution

À l'épreuve E6, la commission te remet une demande d'évolution d'une de tes réalisations, que tu réalises seul en une heure sur ta propre infrastructure, avant la recette (cours Épreuve E6 SISR). Voici une demande typique sur une réalisation Debian.

sudo adduser --comment "Léa Martin (prestataire)" dev-lmartin
sudo usermod -aG web-dev dev-lmartin
sudo chage -E 2027-03-01 dev-lmartin     # refusé à partir du 1er mars 2027 : le compte sert jusqu'au 28 février inclus

sudo install -d -m 700 -o dev-lmartin -g dev-lmartin /home/dev-lmartin/.ssh
sudo install -m 600 -o dev-lmartin -g dev-lmartin lea.pub /home/dev-lmartin/.ssh/authorized_keys
sudo passwd -l dev-lmartin             # pas de mot de passe utilisable : clé seulement
sudo sshd -t && sudo systemctl reload ssh

lsblk                                               # repérer le nouveau disque, par exemple sdd
sudo parted /dev/sdd --script mklabel gpt mkpart medias ext4 0% 100%
sudo mkfs.ext4 -L medias /dev/sdd1
sudo mkdir -p /srv/www/medias
echo 'LABEL=medias /srv/www/medias ext4 defaults,nofail,nodev,nosuid,noexec 0 2' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload && sudo mount -a
sudo chown root:web-dev /srv/www/medias
sudo chmod 2770 /srv/www/medias
sudo setfacl -m u:www-data:rX /srv/www/medias
sudo setfacl -d -m u:www-data:rX /srv/www/medias
sudo setfacl -d -m g::rwx /srv/www/medias

Cas type E7 SISR : analyser un serveur compromis

À l'écrit E7, tu analyses des extraits de journaux et de configurations fournis dans le dossier documentaire, et tu proposes des mesures (cours Épreuve E7 SISR).

nov. 03 23:41:08 web01 sshd-session[9112]: Failed password for deploy from 198.51.100.23 port 40112 ssh2
nov. 03 23:41:11 web01 sshd-session[9112]: Failed password for deploy from 198.51.100.23 port 40112 ssh2
nov. 03 23:47:52 web01 sshd-session[9530]: Accepted password for deploy from 198.51.100.23 port 40990 ssh2

PasswordAuthentication yes
PermitRootLogin prohibit-password

*/5 * * * * /home/deploy/.cache/.x/upd >/dev/null 2>&1

deploy ALL=(ALL) NOPASSWD: ALL