Dépannage de filesystem à distance

J’ai appris quelques trucs suite à un plantage système. Rien d’exceptionnel, mais deux astuces utiles quand on doit réparer le filesystem d’un serveur debian via SSH.

Sommaire

Contexte

Quelques uns de mes services ne répondaient plus un beau matin. Évidemment, ça se produit quand je suis en vacances loin de chez moi…

Bon, en me connectant en SSH sur la machine concernée, je constate des erreurs d’I/O sur un des disques du serveur (en réalité, il s’agit de cartes SD).

Lancer un fsck sur le filesystem root au redémarrage

Au début je croyais que c’était sur le filesystem root. Et impossible de faire un fsck s’il est monté.

Pour lancer le fsck au redémarrage du système, avant que le filesystem soit monté, je connaissais déjà :

touch /forcefsck

… sauf qu’il faut être connecté physiquement sur la machine pour voir ce qu’il fait, et surtout pour répondre à ses éventuelles questions.

Donc attention à ne pas faire ça quand on est loin de la machine : s’il y a une erreur sur le filesystem, la machine attendra une réponse de l’utilisateur… que vous ne pourrez jamais donner et vous ne pourrez plus vous y connecter en SSH.

Heureusement, il est possible de configurer debian pour qu’il corrige automatiquement les erreurs de filesystem lors du fsck au démarrage.
Il faut modifier la dernière ligne dans /etc/default/rcS :

FSCKFIX=yes

(à utiliser avec précaution bien sûr. J’avais une sauvegarde au cas où les corrections fassent pire qu’avant, et j’ai enlevé cette option depuis)

Ensuite, si on reboote avec le /forcefsck, il corrige ce qu’il peut sur le filesystem concerné (sans rien demander) puis termine le démarrage.

Forcer le redémarrage du serveur

Que faire quand la commande reboot n’arrive pas à le faire redémarrer?

Tenter d’abord :

reboot -f

Et si ce n’est pas mieux, la méthode forte (qui revient à débrancher/rebrancher violemment l’alimentation) :

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Source : http://www.yakakliker.org/Linux/Forcer_le_red%C3%A9marrage_d%27un_Linux_%C3%A0_distance

Ce qu’il s’était passé dans mon cas

En fait, ce n’était pas le disque système qui posait problème (ça m’apprendra à ne pas regarder les logs correctement), mais un autre (qui est aussi une carte SD).

Dans /var/log/kern.log, il y avait des erreurs :

[mmc-err] update clock timeout, fatal error

Damned, il semblerait que la carte SD soit complètement morte? Quelques reboots ne changent rien à l’affaire.

Heureusement, j’ai une sauvegarde quotidienne (automatique) de tous mes serveurs. Donc j’ai repris les données de la veille, les ai copiées sur un autre filesystem (qui, heureusement, avait la place suffisante), et ai créé des symlinks pour qu’il les trouve. Ouf…

De retour chez moi, la carte SD n’a a priori pas de problème (fsck -f me dit que tout est ok). Je pense qu’elle était simplement un peu sortie de son emplacement, et que les contacts ne se faisaient plus correctement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *