La mise à niveau du noyau Azure empêche le démarrage de MongoDB en raison d'une incompatibilité rseq

Une matinée habituelle s'est transformée en panne urgente pour une équipe de développement lorsque leur application a cessé de répondre, sans aucun déploiement récent de code ni modification de configuration. La cause racine a été identifiée comme étant une mise à niveau automatique du noyau Linux effectuée par Azure durant une fenêtre de maintenance, introduisant une incompatibilité avec l'instance MongoDB en cours d'exécution.

Ce qui s'est passé

L'incident a commencé lorsque les utilisateurs ont signalé des échecs de connexion, incitant l'équipe d'ingénierie à vérifier l'état de leur machine virtuelle Azure. Après s'être connectés, ils ont constaté que le service MongoDB était dans un état défaillant, se terminant presque immédiatement après les tentatives de démarrage avec des codes de sortie indiquant un échec rapide entre 35 et 48 millisecondes. Les journaux d'application standards ne fournissaient aucune information utile, affichant uniquement un arrêt propre datant de plusieurs jours, ce qui a forcé l'équipe à approfondir ses recherches dans les journaux système.

En filtrant le journal système pour les erreurs fatales, l'équipe a découvert un message d'erreur spécifique indiquant que MongoDB ne peut pas démarrer sur les versions du noyau Linux 6.19 et supérieures en raison d'une incompatibilité connue. La plateforme Azure avait silencieusement mis à niveau le noyau de la VM vers la version 7.0.0-1014-azure, basée sur la lignée problématique 6.19+. Cela a déclenché un blocage de sécurité strict dans MongoDB version 8.0.29, empêchant le démarrage de la base de données afin d'éviter toute corruption potentielle des données ou instabilité liée à l'appel système rseq.

Détails clés

• Déclencheur : Azure a automatiquement mis à niveau le noyau Linux sur la VM durant une fenêtre de maintenance programmée.
• Incompatibilité : MongoDB 8.x refuse de démarrer sur le noyau Linux 6.19 et supérieur en raison de problèmes liés à l'appel système rseq.
• Identification de l'erreur : Le problème a été confirmé via les journaux journalctl, et non via les journaux d'application MongoDB standards.
• Correctifs infructueux : La modification des permissions de fichiers, la suppression des fichiers de verrouillage et la mise à niveau de MongoDB vers la version 8.0.32 n'ont pas résolu le problème.
• Résolution : L'équipe a démarré sur un noyau plus ancien et compatible (6.17.0-1022-azure) en modifiant la configuration GRUB.
• Prévention : Les paquets du noyau ont été épinglés à l'aide de apt-mark hold pour empêcher les futures mises à niveau automatiques tant qu'un correctif officiel n'est pas disponible.

Contexte

Les systèmes Linux utilisent un chargeur de démarrage appelé GRUB (Grand Unified Bootloader) pour sélectionner la version du noyau à charger au démarrage du serveur. Les fournisseurs cloud comme Azure installent souvent de nouveaux noyaux lors des maintenances mais conservent les anciennes versions sur le disque. Par défaut, GRUB sélectionne le noyau le plus récent, ce qui peut entraîner des comportements inattendus si ce nouveau noyau présente des problèmes de compatibilité avec les logiciels installés. L'appel système rseq (restartable sequences) est une optimisation de performance dans les noyaux Linux récents que certaines applications, y compris MongoDB, peuvent ne pas encore prendre entièrement en charge ou avec lesquelles elles peuvent entrer en conflit dans des versions spécifiques.

Les gestionnaires de paquets comme apt utilisent des méta-paquets tels que linux-azure pour pointer vers la dernière image de noyau disponible. Lorsque ces méta-paquets sont mis à jour, le système installe le noyau le plus récent et met à jour GRUB pour le démarrer par défaut. Les administrateurs peuvent outrepasser ce comportement en spécifiant manuellement une version du noyau dans la configuration GRUB ou en « retenant » (« holding ») des paquets spécifiques pour empêcher leur mise à jour automatique.

Pourquoi cela compte

Cet incident souligne les risques liés à la dépendance aux mises à jour automatiques de l'infrastructure sans surveillance adéquate ou processus de contrôle des modifications. Pour les équipes exécutant des logiciels auto-hébergés, une mise à niveau silencieuse du noyau peut casser des services critiques pendant la nuit, entraînant des temps d'arrêt significatifs et des efforts importants de dépannage. Le manque de visibilité immédiate sur les changements au niveau de l'infrastructure signifie que les pannes peuvent sembler mystérieuses, gaspillant un temps précieux sur des étapes de débogage irrélevantes telles que la vérification des permissions ou des journaux d'application.

De plus, cela met en évidence l'importance de comprendre la chaîne de dépendances entre les composants du système d'exploitation et les logiciels applicatifs. Même les versions stables et à support à long terme des bases de données peuvent avoir des contraintes strictes concernant les versions du noyau. Sans gestion proactive des mises à jour du noyau, les organisations risquent de rencontrer des blocages similaires lorsque les fournisseurs cloud poussent de nouvelles versions sous-jacentes du système d'exploitation. Ceci est particulièrement pertinent pour les petites et moyennes entreprises qui peuvent ne pas disposer d'équipes dédiées à la fiabilité des sites (SRE) pour gérer ces détails de bas niveau.

Ce que vous pouvez faire

• Surveiller les versions du noyau : Vérifiez régulièrement les versions du noyau installées et actives sur vos VMs en utilisant uname -r et dpkg --list | grep linux-image.
• Épingler les paquets critiques : Utilisez apt-mark hold sur les méta-paquets du noyau pour empêcher les mises à niveau automatiques susceptibles d'introduire des incompatibilités.
• Configurer les délais d'attente de GRUB : Définissez un GRUB_TIMEOUT non nul dans /etc/default/grub pour permettre la sélection manuelle du noyau au démarrage si nécessaire.
• Vérifier la compatibilité : Avant d'autoriser les mises à jour du noyau, consultez les notes de version de vos applications principales (comme MongoDB) pour connaître les incompatibilités connues avec le noyau.
• Améliorer l'alerte : Mettez en œuvre une surveillance qui alerte sur les échecs de démarrage des services et les erreurs du journal système, et pas seulement sur les contrôles de santé au niveau de l'application.
• Documenter les étapes de récupération : Conservez un runbook pour effectuer un retour arrière des versions du noyau via GRUB, incluant les commandes pour mettre à jour le chargeur de démarrage et redémarrer en toute sécurité.