SysRq sous Linux : reprendre la main sur une machine figée sans couper le courant

\n

\n \n\n

Quand Linux ne répond plus, le clavier peut encore permettre de reprendre la main sans couper brutalement l’alimentation. La fonction Magic SysRq envoie des commandes directement au noyau. Elle ne répare pas tous les blocages, mais elle permet souvent de synchroniser les disques, de remonter les systèmes de fichiers proprement et de redémarrer une machine qui ne répond plus à l’interface.

Avant de l’utiliser sur un serveur distant, vérifiez toutefois que vous avez une console hors bande ou un accès fournisseur. Une séquence SysRq mal choisie ne remplace pas un diagnostic.

Vérifier si SysRq est activé

La configuration se lit avec sysctl :

sysctl kernel.sysrq
cat /proc/sys/kernel/sysrq

Une valeur nulle désactive l’interface clavier. Une valeur positive l’active, avec des restrictions possibles selon les commandes autorisées par le noyau. Vous pouvez l’activer temporairement pour un test :

sudo sysctl -w kernel.sysrq=1

Pour conserver ce réglage après redémarrage, créez plutôt un fichier dédié dans /etc/sysctl.d/, puis rechargez-le avec sudo sysctl --system. Sur une machine exposée, n’activez pas cette fonction sans vérifier qui peut accéder à la console physique ou virtuelle.

La séquence REISUB, sans la réciter aveuglément

Depuis la console locale, maintenez Alt et Impr. écran, puis appuyez successivement sur les touches suivantes, en laissant une seconde entre chaque commande :

R E I S U B

• R tente de reprendre le clavier en mode XLATE ;
• E demande l’arrêt propre des processus ;
• I envoie un arrêt forcé aux processus restants ;
• S synchronise les systèmes de fichiers ;
• U tente de remonter les systèmes de fichiers en lecture seule ;
• B redémarre immédiatement.

Les premières touches peuvent ne produire aucun retour visuel. C’est normal. La séquence réduit le risque lié à un redémarrage électrique, mais elle ne garantit pas que les données en mémoire seront toutes écrites. Attendez quelques secondes entre les étapes et n’utilisez pas B avant d’avoir laissé S puis U agir.

Utiliser /proc/sysrq-trigger pour un diagnostic ciblé

Depuis un shell root encore disponible, les commandes peuvent être envoyées directement au noyau :

echo h | sudo tee /proc/sysrq-trigger
echo w | sudo tee /proc/sysrq-trigger
echo t | sudo tee /proc/sysrq-trigger

h affiche l’aide, w signale les tâches bloquées dans le noyau et t demande une trace des tâches. Les messages apparaissent généralement dans le journal du noyau. Vous pouvez ensuite les lire avec :

sudo journalctl -k -b --no-pager | tail -n 80

Ce chemin est différent du raccourci clavier : il demande déjà un shell fonctionnel et des droits administrateur. Il sert donc au diagnostic, pas à récupérer une session totalement figée.

Ce qu’il faut vérifier après le redémarrage

Une fois la machine revenue, consultez le démarrage précédent et recherchez les erreurs noyau :

sudo journalctl -b -1 -p warning..alert --no-pager
sudo journalctl -k -b -1 --no-pager | tail -n 120
uptime

Si le blocage se répète, ne vous contentez pas de mémoriser REISUB. Cherchez une saturation mémoire, une erreur disque, un pilote qui boucle ou un problème matériel. L’article sur la lecture des messages noyau avec dmesg peut compléter le diagnostic. Pour un redémarrage planifié quand la machine fonctionne encore, utilisez plutôt systemctl reboot.

Enfin, ne testez pas /proc/sysrq-trigger avec des lettres prises au hasard sur un serveur de production. Les commandes disponibles incluent des opérations de synchronisation, de journalisation et de gestion des processus, mais aussi des actions beaucoup plus brutales. Gardez une console de secours et documentez la séquence retenue.

\n

\n \n\n