// HEISE ONLINE — LINUX & OPEN SOURCE
Reboots nach Kernel-Absturz? Kmorph hat da schon mal was vorbereitet
Mit Kmorph übernimmt ein zweiter Linux-Kernel bei einem Absturz in Sekunden das System. Auch Live-Updates sind damit möglich.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Unter dem Namen Kmorph hat Linux-Entwickler Cong Wang ein praktisches, aber noch experimentelles Werkzeug vorgestellt: Ein bereits gestarteter zweiter Kernel soll nach einem Absturz das System übernehmen, ohne den Rechner neu zu starten. Über denselben Mechanismus lassen sich auch geplante Kernelupdates einspielen.
In seiner Ankündigung gibt Wang rund eine Sekunde von der Fehlererkennung bis zum laufenden Nachfolger an. Ein vorbereiteter Nginx-Dienst habe in Tests binnen zwei Sekunden nach dem Kernelabsturz wieder Anfragen beantwortet. Laut der Projektbeschreibung auf GitHub benötigt Kmorph einen Kernel mit Multikernel-Erweiterungen. Unterstützt werden derzeit x86-64 und ARM64.
Grundlage sind die Multikernel-Erweiterungen für Linux. Mit ihnen laufen mehrere Linux-Kernel parallel auf derselben Maschine, jeweils mit eigenen CPUs, Speicherbereichen und Geräten. Ein Hypervisor ist dafür nicht nötig. Kmorph startet den Reservekernel vorab auf wenigen, frei konfigurierbaren CPUs und einem Teil des Arbeitsspeichers. Dort überwacht der Daemon kmorphd den bisherigen Kernel über vsock.
Bleiben die Antworten wiederholt aus, beginnt die Übernahme. Zunächst stoppt der Nachfolger die CPUs des bisherigen Kernels und lässt sich bestätigen, dass sie tatsächlich angehalten haben. Dieses Fencing verhindert, dass beide Kernel auf dieselben Ressourcen zugreifen. Kann der Nachfolger eine CPU nicht sicher stoppen, setzt er die Übernahme nicht fort. Anschließend übernimmt er die Geräte, setzt sie soweit möglich zurück und stellt die Netzwerkkonfiguration wieder her. Die übrigen CPUs und den verfügbaren Speicher bindet er per Hotplug ein.
Auf Wunsch sichert Kmorph außerdem einen kdump-kompatiblen vmcore mit dem Speicherinhalt, CPU-Registern und VMCOREINFO des abgestürzten Kernels. Erst nach dem Schreiben des Dumps gibt es den dafür zurückgehaltenen Speicher zur Nutzung frei. Anders als beim üblichen kdump-Ablauf muss dafür weder ein Capture-Kernel nach dem Absturz starten noch anschließend die Maschine erneut ins Produktionssystem booten.
Die laufenden Prozesse des alten Kernels setzt Kmorph nicht fort. Im Normalfall startet der Userspace nach der Übernahme neu. Um diese Wartezeit für ausgewählte Dienste zu vermeiden, kann Kmorph sie schon im Reservekernel starten. Die Dokumentation zu Standby-Diensten zeigt dafür beispielsweise die Konfiguration standby = nginx.service.
Der Dienst läuft dann bereits, bevor der bisherige Kernel ausfällt. Seine Ports kann er an die vorgesehenen IP-Adressen binden, obwohl der Nachfolger noch keine Netzwerkkarte besitzt. Bei der Übernahme bekommt der Reservekernel die Netzwerkkarte und stellt unter anderem MAC-Adresse, IP-Adressen und Routen wieder her. Danach wechselt er mit pivot_root auf das reguläre Root-Dateisystem. systemd startet die übrigen Dienste; der vorbereitete Nginx-Prozess muss dafür nicht anhalten. Ein vollständig unterbrechungsfreier Betrieb ist laut Wang ein Entwicklungsziel.
Jedoch hat das Verfahren Grenzen: Standby-Dienste müssen zunächst ohne Datenträger und Netzwerkzugriff auskommen. Sie dürfen in dieser Phase keinen Zustand schreiben, der dauerhaft erhalten bleiben muss. Dienste mit eigenen Mount-Namespaces, etwa durch PrivateTmp= oder ProtectSystem=, muss Kmorph nach dem Wechsel neu starten, sofern kein Drop-in ihre Sandbox lockert. Für sie entfällt damit der Vorteil des vorgezogenen Starts.