Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

• • Premier diagnostic
  • Eh bien des requêtes habituelles…
  • La boucle sans fin
  • Une dernière page d’epub ?
  • Retour en graphiques sur la journée
  • Mesures préventives et correctives
  • Bonus inattendu pour l’incident précédent du 26 juin 2025

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

• mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
• procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
• vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
• mettre des limites sur des processus particuliers (comme ceux de pygments)
• ajouter le déploiement des limites par utilisateur dans le code Ansible
• corriger la collecte rrd des métriques concernant les interfaces réseau
• remonter les alertes OOM qui ne sont pas normales
• comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.

Une nouvelle édition de la Fête des Possibles aura lieu du 12 septembre au 12 octobre 2025. Des centaines d’événements seront organisés partout en France et en Belgique pour rendre visibles les initiatives citoyennes qui contribuent à construire un avenir plus durable et solidaire.

Le logiciel libre a toute sa place dans cette dynamique ! Ainsi, l'April, partenaire de la Fête des Possibles, invite les organisations locales de promotion du logiciel libre et de la culture libre à proposer un voire plusieurs rendez-vous dans le cadre de cette initiative.

Initiée et coordonnée par le Collectif pour une Transition Citoyenne (CTC), la Fête des Possibles aspire à faire prendre conscience à un maximum de citoyennes et de citoyens que des solutions existent pour vivre en meilleure santé, pour moins polluer, pour mieux vivre ensemble. C’est aussi l'occasion de montrer à de nouveaux publics que « c’est possible » d’utiliser au quotidien des logiciels respectueux de nos libertés !

Pour cette nouvelle édition de la Fête des Possibles, l'équipe d'organisation a voulu davantage mettre en valeur l'informatique libre : ainsi, des formats d'animation autour du logiciel libre sont désormais suggérés sur le site de la manifestation.

Concrètement, comment participer ?

• Si vous avez déjà prévu un événement autour du logiciel libre ou de la culture libre entre le 12 septembre et le 12 octobre 2025, pensez à l'ajouter sur le site de la Fête des Possibles, en indiquant la thématique « Vivre et faire autrement » ;
• Vous pouvez aussi proposer un rendez-vous ad hoc pour la Fête ! Dans ce cas, n'hésitez pas à l'ajouter sur le site de la Fête des Possibles dès que vous connaissez la date, il sera toujours possible d'affiner la présentation plus tard ;​
• Vous pouvez, sans doute aussi, vous « greffer » à un événement déjà prévu, en proposant à l'organisation de prévoir de la place pour de la sensibilisation au logiciel libre : vérifiez sur la carte des rendez-vous si des événements sont déjà programmés près de chez vous ;
• Votre événement se déroule en ligne ? Il est possible de le préciser dans le formulaire de soumission 👍​

Pour permettre à l'April de mettre en valeur la contribution des organisations autour du Libre, nous vous invitons à inscrire votre événement également sur l'Agenda du Libre, en ajoutant le mot-clé fete-des-possibles-2025.

Préparez dès maintenant votre événement, et rendez-vous du 12 septembre au 12 octobre 2025 pour agir avec la Fête des Possibles !

GNU Taler est un système de paiement conçu pour les transactions financières les plus courantes dans tout type de devise (euros, dollars, bitcoins…), développé depuis dix ans à l’initiative de l’Inria et sorti officiellement en 1.0 au mois de mai. Il permet depuis cette date d’effectuer des transactions en francs suisses, mais il fonctionnait d’ores et déjà comme une monnaie locale à Bâle, sur les distributeurs de boissons de la Haute école spécialisée bernoise, et avec des cryptomonnaies comme Bitcoin ou Ethereum. Dans la zone euro, c’est la banque allemande GLS qui devrait rendre Taler disponible pour tous ses sociétaires au cours de l’été 2025, suivi par la banque hongroise MagNet en 2026.

Taler n’est pas une crypto-monnaie, ni une blockchain. Selon les mots de Christian Grothoff, professeur à l’université de Berne et contributeur au projet, « vous pouvez envisager GNU Taler comme une approche alternative pour construire quelque chose comme l’euro numérique, mais avec des considérations supplémentaires que la banque centrale européenne ne semble pas avoir, comme les droits humains ».

Bien que Taler ne soit pas une monnaie, du point de vue de l’acheteur, il « se comporte comme de l’argent liquide » : « quand vous le dépensez, vous avez la même discrétion [privacy] qu’avec du liquide ». Ce n’est qu’au moment où le vendeur verse la somme payée sur son compte en banque que celle-ci peut être identifiée (le “T” de “Taler” signifie “taxable”). Cela signifie aussi que l’argent que vous utilisez via Taler reste associé à votre appareil : si vous perdez votre téléphone, vous perdez votre porte-monnaie numérique (en contrepartie, votre historique d’achats reste aussi sur votre appareil, et reste donc privé par défaut).

Intégration

Un des enjeux pour permettre à Taler de décoller sera l’intégration de ce moyen de paiement chez une masse critique de commerçants, qui elle même ne sera possible qu’une fois les interfaces logicielles / connecteurs disponibles. Pour cela :

• Un portail des intégrations disponibles ou en cours de préparation (dont Magento, WooCommerce, Odoo et Joomla) a été monté
• Une initiative pour financer ces composants logiciels a été mise en place, portée par NLnet, bien connue ici pour soutenir les projets libres.

À propos

Le déploiement est porté par le consortium européen NGI TALER avec des membres des Pays-Bas, Belgique, France, Allemagne, Grèce, Hongrie, Luxembourg et Suisse.

Le premier point de vente physique acceptant les Taler a été mis en place dans la Haute école spécialisée bernoise en 2020.

Nous (NdM: équipe d'organisation de Kernel Recipes) sommes fiers de vous annoncer la 12e édition de Kernel Recipes. Elle aura lieu du 22 au 24 septembre 2025 à Paris. Comme les années précédentes, une vingtaine d'interventions reatives au fonctionnement de la communauté, des outils, la question de l'usage de Rust, de la sécurité… Le programme est en ligne et quasiment complet.

Le parrain de cette édition : Paul McKenney

Cette année, nous avons l’immense honneur d’accueillir Paul E. McKenney en tant que parrain de l’édition. Contributeur incontournable du noyau Linux depuis plus de 30 ans, connu pour son travail sur RCU (Read-Copy-Update), Paul proposera un talk sur RCU avec probablement des surprises sur scène au programme.

Charity auctions

Comme tous les ans nous mettons à l'honneur une association pour tenter d'apporter une contribution. Cette année, il s'agit des Restos du Coeur. Plus précisément, les fonds récoltés seront destinés à l’entretien et au développement de leur infrastructure informatique, entièrement gérée par des bénévoles, et essentielle au bon fonctionnement quotidien de l’organisation.

Julien Briault, bénévole qui s’en occupe le soir après son travail, sera présent pour nous parler de son engagement et de son rôle.

La billetterie est ouverte !

Les places sont désormais disponibles, alors ne tardez pas à réserver la vôtre. Ne tardez pas, la moitié des places est déjà partie ! Vous êtes étudiants, contactez-nous pour bénéficier d'une remise de 50% sur les entrées.

Dans la salle

Notre "flying mic" fait peau neuve et continuera à favoriser les échanges lors des interventions. Frank TIZZONI sera également de la partie pour croquer sur le fait particpants et orateurs. Jean-Christophe Huwette (Uweti) sera à la manoeuvre pour le son et l'image et grâce à lui nous proposerons cette année encore un live stream de la conférence.

Un grand merci à nos sponsors

Kernel Recipes ne pourrait pas exister sans le soutien fidèle de ses sponsors : Meta, ARM, Collabora, HAProxy, Igalia, jumptrading, The Linux Foundation, Cyberzen, Linux Pratique. Ils nous permettent de conserver la conférence accessible à tous et proposer un environnement propice aux échanges.