Azure-Kernel-Update verhindert MongoDB-Start aufgrund von rseq-Inkompatibilität

Ein routinemäßiger Morgen wurde für ein Entwicklungsteam zu einem dringenden Ausfall, als ihre Anwendung ohne kürzliche Code-Bereitstellungen oder Konfigurationsänderungen nicht mehr reagierte. Als Ursache wurde ein automatisches Linux-Kernel-Upgrade identifiziert, das Azure während eines Wartungsfensters durchgeführt hatte und eine Inkompatibilität mit der laufenden MongoDB-Instanz verursachte.

Was passiert ist

Der Vorfall begann, als Benutzer Verbindungsfehler meldeten, woraufhin das Engineering-Team den Status ihrer Azure-Virtual-Machine untersuchte. Nach dem Login stellten sie fest, dass sich der MongoDB-Dienst im Fehlerzustand befand und fast unmittelbar nach Startversuchen mit Exit-Codes abbrach, die einen schnellen Fehler innerhalb von 35 bis 48 Millisekunden anzeigten. Standard-Anwendungslogs lieferten keine nützlichen Informationen und zeigten nur einen sauberen Shutdown von vor einigen Tagen an, was das Team zwang, tiefer in die System-Journals einzutauchen.

Durch Filtern des System-Journals nach schwerwiegenden Fehlern entdeckte das Team eine spezifische Fehlermeldung, die besagte, dass MongoDB nicht auf Linux-Kernel-Versionen 6.19 und neuer starten kann, aufgrund einer bekannten Inkompatibilität. Die Azure-Plattform hatte den Kernel der VM stillschweigend auf Version 7.0.0-1014-azure aktualisiert, der auf der problematischen 6.19+-Linie basiert. Dies löste eine harte Sicherheitsblockade in MongoDB Version 8.0.29 aus, um den Start der Datenbank zu verhindern, um potenzielle Datenkorruption oder Instabilität im Zusammenhang mit dem rseq-Systemaufruf zu vermeiden.

Wichtige Details

• Auslöser: Azure hat den Linux-Kernel auf der VM während eines geplanten Wartungsfensters automatisch aktualisiert.
• Inkompatibilität: MongoDB 8.x verweigert den Start auf Linux-Kernel 6.19 und neuer aufgrund von Problemen mit dem rseq-Systemaufruf.
• Fehleridentifikation: Das Problem wurde über journalctl-Logs bestätigt, nicht über die standardmäßigen MongoDB-Anwendungslogs.
• Gescheiterte Fixes: Änderungen an Dateiberechtigungen, das Entfernen von Lock-Dateien und das Upgrade von MongoDB auf Version 8.0.32 haben das Problem nicht behoben.
• Lösung: Das Team bootete in einen älteren, kompatiblen Kernel (6.17.0-1022-azure), indem es die GRUB-Konfiguration änderte.
• Prävention: Kernel-Pakete wurden mit apt-mark hold fixiert, um zukünftige automatische Upgrades zu verhindern, bis ein offizieller Fix verfügbar ist.

Hintergrund

Linux-Systeme verwenden einen Bootloader namens GRUB (Grand Unified Bootloader), um auszuwählen, welche Kernel-Version beim Start des Servers geladen werden soll. Cloud-Anbieter wie Azure installieren oft neue Kernel während Wartungsarbeiten, behalten aber ältere Versionen auf der Festplatte bei. Standardmäßig wählt GRUB den neuesten Kernel aus, was zu unerwartetem Verhalten führen kann, wenn der neue Kernel Kompatibilitätsprobleme mit installierter Software hat. Der rseq-Systemaufruf (restartable sequences) ist eine Leistungsoptimierung in neueren Linux-Kernels, die einige Anwendungen, einschließlich MongoDB, möglicherweise noch nicht vollständig unterstützen oder die in bestimmten Versionen damit kollidieren.

Paketmanager wie apt verwenden Meta-Pakete wie linux-azure, um auf das neueste verfügbare Kernel-Image zu zeigen. Wenn diese Meta-Pakete aktualisiert werden, installiert das System den neuesten Kernel und aktualisiert GRUB so, dass dieser standardmäßig gebootet wird. Administratoren können dieses Verhalten überschreiben, indem sie manuell eine Kernel-Version in der GRUB-Konfiguration angeben oder bestimmte Pakete "halten" (hold), um zu verhindern, dass sie automatisch aktualisiert werden.

Warum das wichtig ist

Dieser Vorfall unterstreicht die Risiken, die entstehen, wenn man sich auf automatische Infrastruktur-Updates verlässt, ohne angemessene Überwachung oder Change-Control-Prozesse. Für Teams, die selbst gehostete Software betreiben, kann ein stillschweigendes Kernel-Upgrade kritische Dienste über Nacht zum Absturz bringen, was zu erheblicher Downtime und hohem Debugging-Aufwand führt. Das Fehlen sofortiger Sichtbarkeit auf Infrastruktur-Ebene bedeutet, dass Ausfälle mysteriös erscheinen können und wertvolle Zeit für irrelevante Debugging-Schritte wie die Überprüfung von Berechtigungen oder Anwendungslogs verschwendet wird.

Darüber hinaus betont es die Bedeutung des Verständnisses der Abhängigkeitskette zwischen Betriebssystemkomponenten und Anwendungssoftware. Selbst stabile Long-Term-Support-Versionen von Datenbanken können harte Einschränkungen bezüglich der Kernel-Versionen haben. Ohne proaktives Management von Kernel-Updates riskieren Organisationen, ähnliche Blockaden zu erleben, wenn Cloud-Anbieter neue zugrunde liegende OS-Versionen bereitstellen. Dies ist besonders relevant für kleine und mittlere Unternehmen, die möglicherweise keine dedizierten Site-Reliability-Engineering-Teams haben, um diese Low-Level-Details zu verwalten.

Was Sie tun können

• Kernel-Versionen überwachen: Prüfen Sie regelmäßig die installierten und aktiven Kernel-Versionen auf Ihren VMs mit uname -r und dpkg --list | grep linux-image.
• Kritische Pakete fixieren: Verwenden Sie apt-mark hold auf Kernel-Meta-Paketen, um automatische Upgrades zu verhindern, die Inkompatibilitäten einführen könnten.
• GRUB-Timeouts konfigurieren: Setzen Sie einen non-zero GRUB_TIMEOUT in /etc/default/grub, um bei Bedarf eine manuelle Kernel-Auswahl während des Boots zu ermöglichen.
• Kompatibilität überprüfen: Bevor Sie Kernel-Updates zulassen, prüfen Sie die Release Notes Ihrer Kernanwendungen (wie MongoDB) auf bekannte Kernel-Inkompatibilitäten.
• Alerting verbessern: Implementieren Sie Monitoring, das bei Dienststart-Fehlern und System-Journal-Fehlern alarmiert, nicht nur bei Health Checks auf Anwendungsebene.
• Recovery-Schritte dokumentieren: Halten Sie ein Runbook für das Rollback von Kernel-Versionen via GRUB bereit, einschließlich Befehlen zum Aktualisieren des Bootloaders und sicheren Neustart.