La petite panne de DryCat, à quoi c'était dû ?

Informatique 16 mars 2018

Le 13 mars dernier, je rentrais chez moi après une visite chez le médecin et là "pouf" : mon instance Mastodon tombe malade à son tour (Murphy, quand tu nous tiens). J'étais sur le chemin de chez moi, fatigué et pas avec tout mon cerveau, j'ai donc redémarré brutalement le VPS... Il n'a jamais voulu et je pouvais rien faire de plus.

2h écoulées depuis le début de la panne

17h20, je fais un backup et j'essaie d'en restaurer une ancienne (oui, car je l'ai activé deux jours plus tôt "heureusement") : le kernel ne veut même pas booter (problème VMware tout ça bref, j'ai rien compris et je ne pouvais rien faire). Pas grave, j'avais un autre backup, vieux de 48h. Je le mets en place : Kernel panic.
Pas grave, je remets la version en cours (j'avais fais un backup avant de mettre les autres en place) et je lance en rescue. J'ai cherché sur internet, je lisais que je devais utiliser la commande testdisk, fsck, bref, beaucoup de commandes mais aucune ne fonctionnait. la commande e2fsck /dev/sda1 (qui est la même commande que fsck) me retournait

e2fsck 1.42.12 (29-Aug-2014)
/dev/sda1 has unsupported feature(s): metadata_csum 

Et là on me dit que c'est les tables d'allocations qui sont mortes, c'est récupérable mais c'est tendu.
Dans la foulé, j'ai créé un compte de backup sur l'instance de @TheKinrar.
Il est 21h, j'étais en pleine convalescence, autant dire que j'avais besoin de sommeil.

17h écoulées depuis le début de la panne

8h, sur Mastodon des messages de soutien et @victorhery (au passage il a un blog sympathique que je vous conseille d'aller lire)
On retappe sur e2fsck, on chroot, on essaye tout... Le disque est parfaitement montable, entièrement accessible mais fsck ne voulait rien savoir. Ça avait des allures d'inode corrompu, des relents d'inode corrompu mais ça ne voulait pas réagir. Gros backup à coup de SCP... Puis au bout de 4h, je remarque que j'ai transféré que 50% des fichiers car il y avait plein de petits fichiers ridicules... BAM, grosse archive, j'envoie ça sur mon serveur chez moi et on continue à chercher.

21h écoulées depuis le début de la panne

Sur internet, la réponse qu'on a était de mettre à jour la commande e2fsck, mais sous Ubuntu... Donc recherche sur internet si la Debian buster ou sid avait ce paquet. Ils l'ont ! Donc je file ajouter les sources dans le rescue, j'installe le paquet e2fsck-static, j'installe, je tape la commande e2fsck-static et là.... On me demande si je veux réparer cet inode corrompu.

VICTOIRE !!

Bon, Victor me conseil d'ajouter -vtty histoire d'éviter de taper tout les y.
5 minutes plus tard le serveur démarrait, me laissant ça comme souvenir :



/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

     1018935 inodes used (20.85%, out of 4888000)
        1060 non-contiguous files (0.1%)
         475 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 1005593/270
    11113858 blocks used (55.57%, out of 20000507)
           0 bad blocks
           2 large files

      605687 regular files
      399983 directories
           7 character device files
           0 block device files
           1 fifo
  4294966748 links
       13244 symbolic links (13052 fast symbolic links)
           4 sockets
------------
     1017806 files
Memory used: 31124k/0k (2207k/28917k), time: 55.41/ 8.40/ 4.43
I/O read: 2253MB, write: 19MB, rate: 41.00MB/s

Donc DryCat est revenu, mais la panne est pas tombée au bon moment.

Photo par Igor Ovsyannykov on Unsplash
Correction par Von (psst, il a un blog aussi)

Mots clés

Dryusdan

Chasseur de bug et régleur de problème (alias DevOps).