Un serveur qui ne termine pas son démarrage

Vous avez redémarré un serveur après une intervention, et il n'est jamais revenu. Le SSH ne répond plus, et sur la console vous trouvez : You are in emergency mode. Cette page vous apprend à identifier ce qui bloque en une commande, à réparer depuis la console, et surtout à relancer le boot sans redémarrer. Elle vous montre aussi pourquoi les deux commandes que l'on recommande partout, systemctl list-jobs et systemctl --failed, ne servent strictement à rien dans cette situation.

La cause la plus fréquente, de très loin : une entrée /etc/fstab qui pointe vers un périphérique absent, sans l'option nofail. Toutes les sorties ci-dessous viennent d'un serveur AlmaLinux 10 mis dans cet état.

Ce que vous allez apprendre

• Lire ce que la console affiche : trois écrans possibles, trois diagnostics
• Trouver le montage ou le service fautif avec la seule commande qui parle
• Réparer depuis l'emergency shell, y compris quand la racine est en lecture seule
• Relancer le boot sans redémarrer, avec systemctl default
• Prévenir : l'option qui aurait évité l'incident

Comprendre ce que la console affiche

Sans accès SSH, la console est votre seule fenêtre : console du fournisseur cloud, virsh console sur un hyperviseur, ou écran physique. Ce que vous y lisez oriente tout le diagnostic.

Ce que vous voyez	Ce qui se passe	Où aller
A start job is running for... (1min 30s / no limit)	Le boot attend quelque chose : un périphérique, un montage, un réseau. Le compteur monte.	Attendez la fin du délai : vous tomberez en emergency mode, qui vous donnera la main
You are in emergency mode + Give root password	systemd a renoncé. Il vous donne un shell de secours.	C'est le cas traité ici
Une invite GRUB, ou rien du tout	Le problème est avant systemd : noyau, initramfs ou chargeur de démarrage	Voir Arrêter, redémarrer, récupérer

Glissez pour voir

Le A start job is running mérite une explication, parce qu'il fait paniquer pour rien. Le serveur n'est pas planté, il attend. systemd accorde un délai de 90 secondes par défaut à un périphérique attendu. Passé ce délai, il abandonne et bascule en emergency mode. Attendre est donc la bonne action : au bout d'une minute et demie, vous récupérez un shell.

Prendre la main sur la console

L'emergency shell demande le mot de passe root. Saisissez-le, et vous obtenez une invite. Vous êtes maintenant dans un système minimal : la racine est montée, mais presque rien n'est démarré, et le réseau n'est pas configuré.

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.
Give root password for maintenance
(or press Control-D to continue):

Sans mot de passe root, pas d'emergency shell

Si le compte root n'a pas de mot de passe (cas par défaut sur Ubuntu et sur la plupart des images cloud), cette invite est un cul-de-sac : vous ne pouvez pas entrer. Il faut alors passer par GRUB et l'initramfs (rd.break sur RHEL, init=/bin/bash sur Debian), décrits dans Arrêter, redémarrer, récupérer. Définir un mot de passe root sur vos serveurs est ce qui rend cette porte utilisable le jour où vous en avez besoin.

Trouver le coupable : une seule commande fonctionne

C'est ici que la plupart des tutoriels vous égarent. Voici ce que donnent, dans un vrai emergency shell, les deux commandes habituellement recommandées :

systemctl list-jobs
systemctl --failed --no-pager

No jobs running.
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Aucun job en cours. Aucune unité en échec. Tout va bien, apparemment, alors que le serveur est à genoux. L'explication est simple : systemd a déjà abandonné les jobs en attente au moment où il vous a donné le shell, et l'unité de montage n'est pas passée en failed, elle a été annulée. Vous cherchez une trace qui n'existe plus.

La seule source qui a gardé la mémoire de l'incident, c'est le journal du boot courant :

journalctl -b -p err --no-pager | tail

systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-deadbeef\x2d0000\x2d...
            .device - /dev/disk/by-uuid/deadbeef-0000-0000-0000-000000000000.

Tout est là. systemd a attendu un périphérique identifié par son UUID, ne l'a jamais vu apparaître, et a fini par renoncer. L'UUID affiché est celui que vous allez retrouver dans /etc/fstab. Retenez l'option -p err : elle filtre sur les messages de priorité « erreur » et vous évite de lire des centaines de lignes.

Confrontez ensuite avec le fichier fautif :

cat /etc/fstab

UUID=1f5fce98-2902-4ac3-b784-b4f10857f44e /        xfs   defaults  0 0
UUID=cea79fb2-b54a-4ab3-bd5e-25595813e238 /boot    xfs   defaults  0 0
UUID=deadbeef-0000-0000-0000-000000000000 /donnees ext4  defaults  0 2

La dernière ligne pointe vers un disque qui n'existe pas (ou plus). Un disque retiré, un volume non attaché après une migration, un UUID recopié avec une faute : la cause exacte varie, le symptôme est le même.

Réparer

Vérifier si la racine accepte l'écriture

On lit partout qu'il faut commencer par mount -o remount,rw /. Vérifiez d'abord, plutôt que d'appliquer un rituel :

findmnt -o TARGET,OPTIONS /

TARGET OPTIONS
/      rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

Ici la racine est déjà en rw : le montage a réussi, c'est un autre montage qui a échoué. Il n'y a rien à remonter. Si en revanche vous lisez ro dans cette sortie, alors seulement :

mount -o remount,rw /

Neutraliser la ligne fautive

Corrigez /etc/fstab avec l'éditeur disponible (vi est toujours là). Deux options selon votre besoin : supprimer la ligne si le montage n'a plus lieu d'être, ou la rendre non bloquante avec nofail si le périphérique doit revenir plus tard.

vi /etc/fstab

Puis rechargez la configuration. C'est une étape que l'on oublie, et le fichier /etc/fstab le rappelle lui-même dans ses commentaires : systemd génère des unités de montage à partir de fstab, et il ne les régénère pas tout seul.

systemctl daemon-reload

Relancer le boot sans redémarrer

Inutile de rebooter : demandez à systemd de reprendre son démarrage là où il s'était arrêté.

systemctl default

Le boot reprend, les services démarrent, et le serveur revient en ligne. Vérifiez ensuite depuis SSH :

systemctl is-system-running
systemctl --failed --no-pager
grep deadbeef /etc/fstab

running
0 loaded units listed.

running signifie que toutes les unités du démarrage sont arrivées à bon port. Si vous obtenez degraded, le système fonctionne mais au moins une unité a échoué : systemctl --failed vous dira laquelle, cette fois-ci utilement.

Le boot précédent reste lisible

Une fois le serveur revenu, le journal du boot cassé n'est pas perdu : journalctl -b -1 -p err affiche les erreurs du démarrage précédent. C'est précieux pour le rapport d'incident, et pour vérifier après coup que vous avez bien traité la cause et pas seulement le symptôme.

Prévenir : l'option qui change tout

L'incident entier tient à une option absente. Une entrée /etc/fstab sans nofail est considérée comme critique : si le périphérique manque, systemd refuse de terminer le démarrage. Avec nofail, le montage est tenté, et son échec n'empêche pas le boot :

UUID=... /donnees ext4 defaults,nofail,x-systemd.device-timeout=10 0 2

Deux options, deux effets complémentaires. nofail dit à systemd que ce montage n'est pas vital pour le démarrage. x-systemd.device-timeout=10 réduit l'attente de 90 secondes à 10 : sans elle, votre serveur mettra toujours une minute et demie de plus à démarrer quand le disque est absent, même avec nofail.

La règle : tout montage qui n'est pas indispensable au démarrage doit porter nofail. Les partages réseau, les disques de données, les volumes de sauvegarde sont dans ce cas. La racine et /boot, non : s'ils manquent, il n'y a rien à sauver.

Et le réflexe qui vous évitera l'incident : après toute modification de /etc/fstab, testez le montage sans redémarrer.

mount -a ; echo "exit=$?"
findmnt --verify

Si mount -a échoue, votre prochain reboot échouera aussi. Vous venez de l'apprendre pendant que la machine est encore accessible, ce qui change tout.

Dépannage

Symptôme	Cause probable	Vérification	Correction
A start job is running qui dure	systemd attend un périphérique (90 s)	Attendre : vous tomberez en emergency mode	Corriger la cause, ajouter nofail
You are in emergency mode après un changement de disque	Entrée fstab sans nofail	journalctl -b -p err : Timed out waiting for device	Supprimer la ligne ou ajouter nofail, puis daemon-reload
list-jobs et --failed ne montrent rien	Les jobs ont été annulés, pas mis en échec	journalctl -b -p err, la seule source fiable	Ne pas se fier à ces deux commandes en emergency
L'emergency shell refuse le mot de passe root	Compte root sans mot de passe	Impossible d'entrer	Passer par GRUB : rd.break (RHEL) ou init=/bin/bash (Debian)
Le système démarre mais affiche degraded	Une unité a échoué sans bloquer le boot	systemctl --failed (utile, cette fois)	Traiter l'unité concernée
Le boot est lent depuis un changement de stockage	nofail sans x-systemd.device-timeout	systemd-analyze blame	Ajouter x-systemd.device-timeout=10

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

• A start job is running n'est pas un plantage, c'est une attente. Au bout de 90 secondes, systemd abandonne et vous donne un shell.
• En emergency mode, systemctl list-jobs et systemctl --failed ne montrent rien : les jobs ont été annulés, pas mis en échec. Ne perdez pas de temps dessus.
• journalctl -b -p err est la seule commande qui nomme le coupable. Cherchez Timed out waiting for device.
• Vérifiez avec findmnt -o OPTIONS / avant de remonter la racine : elle est souvent déjà en rw, et le rituel remount,rw ne sert alors à rien.
• systemctl daemon-reload après avoir modifié /etc/fstab : systemd génère ses unités de montage depuis ce fichier et ne les régénère pas seul.
• systemctl default relance le boot sans redémarrer, depuis l'emergency shell.
• nofail sur tout montage non vital, accompagné de x-systemd.device-timeout pour ne pas payer 90 secondes d'attente.
• mount -a et findmnt --verify après chaque édition de fstab, pendant que la machine est encore joignable.

Pour aller plus loin

• Arrêter, redémarrer, récupérer : mode rescue, mode emergency, rd.break et réinitialisation du mot de passe root.
• Monter et rendre persistant : la syntaxe de /etc/fstab et toutes ses options.
• Un système de fichiers en lecture seule : quand le montage réussit mais que les écritures échouent.
• Lire les journaux (journalctl) : filtrer par boot, par priorité, par unité.

×

📖 Voir la documentation →