Il arrive en production qu’une machine Linux refuse catégoriquement de s’éteindre ou de redémarrer. Lorsqu’on lance un classique reboot, shutdown -r now ou init 6, la console peut renvoyer une erreur bloquante telle que Bus error ou figer complètement la session. Ce cas de figure se produit généralement lors d’une défaillance matérielle sur le stockage ou d’une perte d’accès au disque hôte.
Identifier la source du blocage système
Le symptôme d’un Bus error lors de l’exécution d’un binaire découle souvent du passage du système de fichiers en lecture seule (read-only) ou d’erreurs d’entrée/sortie massives. Le shell tente de charger des bibliothèques dynamiques partagées en mémoire vive depuis le disque, mais le périphérique ne répond plus.
Pour confirmer ce diagnostic avant la perte totale d’accès, une analyse du journal matériel s’impose. La commande dmesg permet d’inspecter les événements système en direct. Si vous souhaitez approfondir l’analyse de ces messages, consultez notre guide sur le debug avec dmesg. Vous y observerez souvent des alertes critiques de type hostbyte=DID_BAD_TARGET ou end_request: I/O error, indiquant que le contrôleur SCSI ou SATA a perdu la communication avec le disque.
La solution de secours : Magic SysRq
Puisque les démons d’initialisation (systemd ou sysvinit) ne peuvent plus lire leurs fichiers ou exécuter les scripts de fin de session, il faut s’adresser directement au noyau Linux. Le mécanisme Magic SysRq permet d’envoyer des ordres prioritaires au kernel sans passer par l’espace utilisateur.
Pour utiliser cette méthode, il faut s’assurer que la fonctionnalité est activée au niveau du noyau :
echo 1 > /proc/sys/kernel/sysrq
Redémarrer d’urgence : la méthode brute
Si la machine ne répond plus du tout et que vous souhaitez provoquer un redémarrage immédiat sans tenter de synchroniser quoi que ce soit, vous pouvez injecter l’instruction suivante :
echo b > /proc/sysrq-trigger
Le serveur redémarre instantanément, simulant un appui sur le bouton Reset physique de la machine.
La séquence de secours recommandée (REISUB)
Lorsque le stockage est encore partiellement accessible, il est nettement préférable d’effectuer une fermeture propre des ressources résiduelles afin de ne pas corrompre d’autres partitions. Les administrateurs utilisent pour cela la célèbre séquence mnémotechnique REISUB, appliquée séquentiellement :
- unRaw (r) : Reprend le contrôle du clavier depuis le serveur X ou un terminal bloqué : echo r > /proc/sysrq-trigger
- tErminate (e) : Envoie le signal SIGTERM à tous les processus pour leur demander de s’arrêter proprement : echo e > /proc/sysrq-trigger
- kIll (i) : Envoie SIGKILL à tous les processus réfractaires encore en cours d’exécution : echo i > /proc/sysrq-trigger
- Sync (s) : Tente de synchroniser les données en mémoire cache vers les disques : echo s > /proc/sysrq-trigger
- Unmount (u) : Remonte tous les systèmes de fichiers en lecture seule pour éviter la corruption : echo u > /proc/sysrq-trigger
- reBoot (b) ou off (o) : Lance le redémarrage (b) ou éteint électriquement la machine (o) : echo b > /proc/sysrq-trigger
Entre chaque étape, attendez deux à trois secondes pour laisser au système le temps de terminer l’action demandée. Cette manipulation sauve régulièrement des serveurs distants en évitant un déplacement physique en datacenter. Pour des interventions avancées sur les composants internes du système, apprenez également à gérer un module Linux ou à compiler un noyau Linux personnalisé avec les options de débogage requises.