État du service LIRE.IM

Engage RE.ALIV.RE
9

LIRE.IM : Accident (presque) Fatal

Le 24 janvier 2025, notre service Mastodon a connu un incident qui l’a rendu temporairement indisponible. Une première intervention a remis le service en place. Mais lors de l’investigation sur ses causes, le lendemain une erreur de manipulation a effacé les fichiers (avatars, bannières, photos…), puis une seconde erreur dans la nuit a rendu la base de données inutilisable… ou pas ?

Ce billet dissèque l’incident pour rendre compte de manière transparente de l’enchaînement des événements entraînant la destruction du service et poser les bases d’une éventuelle suite.

tl;dr : nous avons eu chaud, très chaud. Ç’aurait pu être bien pire.

Autopsie

1. OOM Killer : l’exhaustion de mémoire appliquée au cerveau

Dans la soirée du 24 janvier an usagær de LIRE.IM rapporte que le site est indisponible. Je me connecte au serveur et constate que la base de données est stoppée : je la redémarre et vérifie que le service fonctionne bien, en proposant de mener l’enquête le lendemain.

Le 25 janvier, j’ai identifié dans les logs l’invocation d’une fonction du kernel Linux (oomkiller) qu’un processus réclame lorsqu’il n’a pas suffisamment de mémoire. Dans ce cas c’était la base de données.

J’avais installé ce service un peu rapidement en me disant que j’y reviendrais, mais évidemment, ce ne fut pas le cas. Je me mis donc en tête de préparer une mise à jour, d’autant plus que la base de données avait changé de version.

2. Ne jamais bouger des données sans savoir où elles vont

Malheureusement je n’étais pas en grande forme et la fatigue m’a rapidement causé des ennuis. J’ai commencé par faire le ménage : cela prend pas mal de temps lorsque les processus de Mastodon doivent passer à travers de dizaines de milliers de comptes (distants) pour vérifier lesquels utilisent potentiellement de l’espace de stockage pour rien. Pendant ce temps je regardai d’autres choses, comme l’espace disque disponible et me dis que l’un des volumes quasiment vides pourrait être utilisé pour les sauvegardes. J’entrepris donc de transférer des données d’un endroit à un autre. Mais je n’avais pas remarqué – parce que je ne me souvenais pas vraiment de comment cette machine était configuré, et que je luttais contre la fatigue – que le volume que je pensais libérer était en fait déjà monté à l’endroit où je voulais le mettre. En clair, j’ai copié 85Go de fichiers de l’endroit où ils se trouvaient vers… l’endroit où ils se trouvaient. :thinking: Mais voilà, comme je ne m’en suis pas rendux compte, une fois la « copie » effectuée, j’ai effacé la source… donc la seule copie. :scream:

Là : panique. Oh la la, c’est terrible, tout est parti. Et les sauvegardes ? Ben, en fait, comme c’était beaucoup de fichiers et que je n’avais pas mis en place de sauvegarde distante, j’étais en train de faire la première sauvegarde. :expressionless:

OK, des génocides sont en cours dans plusieurs régions du monde, ce n’est pas si grave : les données sont intactes, c’est juste une question de remettre son avatar et sa bannière. Gênant et un peu honteux, mais pas trop grave. J’annonce la problématique et envoie des messages en ce sens, plutôt rassurants.

3. Ne jamais faire en prod ce qu’on peut faire ailleurs

Mais quand même, j’aimerais bien tenter quelque chose… J’ai déjà mis en place un fichier de mémoire tampon pour m’assurer que l’oomkiller ne va plus nous embêter, mais c’est un peu porcasse. En parcourant quelque documentation, je me rends compte que tout de même ce problème de mémoire est relativement courant à partir d’une certaine activité sur Mastodon. Alors je me décide à monter un machine plus puissante, avec plus de mémoire, en mettant en place des scripts qui surveillent l’état des lieux et lancent des alertes : rien de bien inhabituel.

Je lance donc un gros nettoyage et des sauvegardes pour préparer la migration. Cela prend pas mal de temps, du coup je reviens sur cette histoire de fichiers effacés… Peut-être que je peux au-moins récupérer les fichiers par défaut, c’est déjà ça. Pour cela, rien de plus simple : un bon vieux git checkout et c’est marre… :yawning_face: Euh… Cela ne restaure pas les fichiers ? Hum. :yawning_face: Bon ben, git reset --hard. Ah, là ça marche… Service relancé, nouvelle mise à jour de l’info. On est bien.

:yawning_face: Je commence à transférer les fichiers importants… Enfin : le fichier critique .env.production, de la machine en cours de ramonage et la nouvelle clinquante : ssh old:/home/mastodon/live/.env.production new:/home/mastodon/live/.env.production. :yawning_face: Bon, je crois que je finirai demain, personne n’utilise Mastodon le samedi soir ni le dimanche matin.

Après une bonne nuit de sommeil, retour au clavier. Tiens, .env.production est vide ? :thinking: Ha ! Je n’aurais pas dû faire ce git reset, c’était vraiment débile : j’aurai pu cloner le dépôt de nouveau et copier les fichiers. Mais bon, pas grave, je le prends depuis le backup. :sunglasses: Euh… :cold_sweat: Pourquoi n’est-il pas dans le backup ? Je vérifie le script : ben oui, c’est la première chose qu’il fait, copier ce fichier… :sweat_smile: Je relis le script… Oh…

tar zcvf $BACKUP_DIR.tgz $BACKUP_DIR/* && rm -rf $BACKUP_DIR

En clair : t’as codé ça à quat’du mat’ avec tes oreilles. Bon déjà, la destruction du répertoire cible de la sauvegarde pour gagner de la place c’est bien, mais cela ne permet pas de vérifier ce qu’il y a dedans. Donc, le bouger à la fin, quand tout est fait. Mais surtout, surtout… Le tar là, pour créer une archive de ce répertoire, il ne prend pas les « fichiers cachés » (qui commencent par un ., comme… .env.production.

:pleading_face: :woozy_face: :grimacing: :scream: :scream_cat: :skull:

Sans ce fichier, la base de données a beau être intacte, il est impossible de lire ce qu’elle contient. Enfin peut-être pas tout. En passant par le gestionnaire de la base de données et non par Rails, nous pouvons lire certaines choses, mais sera-ce suffisant ?

Rééducation

À présent que nous avons pu identifier les causes des pannes, nous avons mis en œuvre des méthodes pour éviter que ce genre d’erreurs ne se reproduise, qui seront documentées ici-même.

:bulb: Reste l’espoir de pouvoir migrer les comptes et restaurer les messages à partir de la base de données mais sans les secrets, comment cela va-t-al se passer ? Nous ne savons pas vraiment (et sommes curieuz de connaître les conséquences réelles.)

If you lose application secrets, some functions of Mastodon will stop working for your users, they will be logged out, two-factor authentication will become unavailable, Web Push API subscriptions will stop working.

La doc dit : « Si vous perdez les secrets de l’application, certaines fonctions de Mastodon ne fonctionneront plus pour vos usagærs, als seront déconnectæs, l’authentification multi-facteurs ne sera plus disponible et les souscriptions par le biais de l’interface « Web Push » cesseront de fonctionner.

Mais cela ne dit pas si toutes ces fonctionnalités sont récupérables par la suite. Nous verrons bien.

Qu’avons-nous appris ce weekend ?

  1. Sysadmin et fatigue : non. Le surmenage mène à la faute. Les geeks ont tendance à penser que le sommeil est optionnel. Et bien non, pas du tout. Et si vous n’arrivez pas à dormir c’est peut-être que vous passez trop de temps sédentaire devant un ordinateur.
  2. Ne jamais déplacer des données dans le vide. À moins d’être en apesanteur, c’est comme poser une tasse de café en suspension dans l’air : la gravité s’en charge, et après vous devez nettoyer. Même si vous pensez savoir, vérifier quand même comment les montages sont faits.
  3. Vérifier les sauvegardes : c’est con, mais c’est indispensable. Un fichier manquant et cela peut être fatal.
  4. Ne jamais faire en production ce qu’øn peut faire ailleurs. Là encore, c’est évident mais dans le feu de l’action, avec l’exaltation du travail sans filet du super-utilisateur, c’est facile de faire une boulette… sans retour. Alors que c’est tellement simple de tester une hypothèse. Deux précautions valent mieux qu’une.

Relance

Si vous aviez un compte sur https://lire.im/, je suis vraiment désolæ des erreurs commises et des conséquences négatives qu’elles peuvent avoir pour vous. Je vous demande humblement pardon et je fais tout ce qui est possible pour que ce genre d’incident ne se reproduise pas.

Je vous engage à répondre à ce sujet pour engager une discussion sur l’avenir de ce service.

Si vous avez perdu confiance et que vous désirez ouvrir un compte ailleurs, je comprendrai et je vous soutiendrai, mais je regretterai votre absence. :broken_heart:

Cependant si vous désirez réactiver votre compte, vous devez :

  1. Vous connecter (apparemment les mots de passe sont inchangés)
  2. Vous rendre sur votre profil pour remettre votre avatar et votre bannière
  3. Engueuler le sysadmin ou le réconforter, selon votre humeur : je le prendrai bien.

Merci de votre attention. :two_hearts:

Plan d’action

Ces mesures visent à assurer la pérennité du service. Les coches marquent les actions en place.

  • Installation d’un serveur plus puissant
  • Correction du script de sauvegarde
  • Respect des conditions du Mastodon Server Covenant
  • Surveillance automatisée des conditions de service