Kernel-Crashdumps aufsetzen und auswerten

© © Stephen Sweet, Fotolia

Flugschreiber

Crasht der Linux-Server, steht neben der Wiederherstellung auch die Problemanalyse an: Was ist genau passiert, wo liegt der Fehler, welche vorbeugenden Maßnahmen sind nötig? Ein Kernel-Crashdump vom Zeitpunkt des Absturzes kann hierbei helfen.
Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Ein Dump des Betriebssystem-Kernels als Mittel zur Problem-Analyse ist in der Unix-Welt an sich ein alter Hut. Unter Linux lag dieses Thema aber lange Zeit brach. Die ersten Versuche erfolgten im Jahr 1999 mit dem Projekt LKCD (Linux Kernel Crash Dump) [1]. Dieser ursprünglich von SGI iniitierte Ansatz war insoweit erfolgreich, dass er sogar Einzug in die Enterprise-Distribution von Suse fand [2]. Die Probleme beim Schreiben des Dumps auf ein MD-RAID oder die Übertragung größerer Kernel-Images waren letztlich aber nicht zu beheben.

Weitere Versuche mit Netdump (Red Hat) oder Diskdump [3] in den Jahren 2002 beziehungsweise 2004 hatten auch nur mäßigen Erfolg. Mittlerweile gibt es mit Kdump und Kexec ([4] bis [7]) einen Ansatz, der in der Praxis zuverlässig einsetzbar ist. Eine Kern-Frage und gleichzeitig auch die größte Herausforderung beim Schreiben des Kernel-Dumps ist: Wer soll es machen? Die naheliegende Antwort lautet sicherlich: der Kernel selbst. Dieser Ansatz, den auch das LKCD-Projekt verfolgte, birgt aber einige Gefahren.

Wie weit kann man dem Kernel, der ja gerade abgestürzt ist, vertrauen? Sind die Kernel-Strukturen und Daten intakt? Sind die Treiber noch richtig initialisiert, sodass die Festplatte oder der NFS-Share ansprechbar ist? Genau auf diese Probleme ist LKCD auch gestoßen.

Besser wäre hier eine dem Kernel externe Instanz, die das Speichern des Kernel-Dumps übernimmt. Mit zunehmender Verbreitung der Virtualisierung ist der Hypervisor dafür ein naheliegender Kandidat. Tatsächlich ist es möglich, mit VMware, Xen oder KVM einen Dump des Linux-Kernels zu speichern, doch dazu später mehr.

Läuft Linux direkt auf dem Blech, nützt der Hypervisor-Ansatz nichts. Hier kommt Kdump ins Spiel, genauer gesagt Kexec, eine Art Kernel-zu-Kernel-Bootloader. Der laufende Kernel kann über »kexec« einen neuen Kernel direkt laden und ausführen. Das BIOS bleibt aus dem Spiel, und es ist dem neuen Kernel überlassen, ob er den Speicherinhalt unberührt lässt oder bestimmte Einträge löscht.

Dieser neue Kernel, auch Crash- oder Dump-Kernel genannt, startet einen Teil des restlichen Linux-Systems und speichert den Dump. Damit Kexec funktionieren kann, benötigt der Admin drei Dinge: einen Kernel neuer als 2.6.13, einen Kernel, der für Kexec konfiguriert ist und die entsprechenden Userland-Werkzeuge (Abbildung 1).

Abbildung 1: Voraussetzungen für Kdump/Kexec sind sowohl im Kernel- als auch im User-Land nötig.

Kernel lädt Kernel

Das Booten eines neuen Kernels aus dem Kontext eines laufenden Kernels klingt einfacher als es ist. Vor Version 2.6.26 konnte der Linux-Kern nur von einer einzigen vorgegebenen Speicheradresse starten, und diese war natürlich schon vom laufenden Kernel belegt. Zweitens benötigt der Speicherbereich des neuen Kernels einen Schutz vor dem Überschreiben der Daten durch die ständig erfolgenden direkten Zugriffe auf den Hauptspeicher (DMA). Schließlich muss der neue Kernel auf bestimmte Informationen aus der Zeit des Absturzes zugreifen, muss also wissen, wo der alte Betriebssystem-Kern im Speicher liegt. Glücklicherweise muss sich der Administrator aber nicht mit dieser scheinbar aussichtslosen Mission beschäftigen. Dies erledigen das Kommando »kexec« und der Systemaufruf »kexec_load« . Ersteres lädt den neuen Kernel in einen reservierten Speicher-Bereich und ist im Zusammenspiel mit dem Systemcall für die Ausführung zuständig.

Die konkrete Konfiguration des Kexec/Kdump-Gespanns ist im Detail für jede Linux-Distribution etwas unterschiedlich. Daher erläutert dieser Artikel das Vorgehen auf einem etwas allgemeineren Level anhand von Red Hats und Suses Enterprise-Distributionen (RHEL 6.2 und SLES 11 SP2). Der Admin hat dabei die Wahl zwischen einer komplett manuellen Konfiguration mit »rpm« und »vi« beziehungsweise »emacs« oder der Verwendung des Systemwerkzeuge des Herstellers. Im Falle von SLES ist es das »yast2-kdump« -Modul, bei RHEL kommt »system-config-kdump« zum Einsatz.

Zunächst muss der Admin die Werkzeuge zum Booten des Crash-Kernels und zum Schreiben des Dumps installieren. Das entsprechende Paket heißt üblicherweise »kexec-tools« oder ähnlich. Eventuell ist das Aufspielen des Crash-Kernels nötig. Bei älteren Distributionen gibt es dafür ein separates Paket. Hier lädt »kexec« eine neue Binär-Datei.

Kernel zum Crashen

Heute gehen die Distributoren einen anderen Weg: Der normal installierte Kern ist mit allen Funktionen ausgestattet und kann auch als Crash-Kernel dienen. Dies ist der Fall für die aktuellen Varianten von RHEL und SLES – das Aufspielen eines weiteren Kernel-Paketes entfällt.

Der nächste Schritt ist die Konfiguration von »kexec« und »kdump« . Ersteres ist für das Laden und Ausführen des Crash-Kernels zuständig. Dazu muss das Tool wissen, welcher Kernel zu laden ist, wo er sich befindet und ob eventuell zusätzlich Kernel-Optionen nötig sind. Die Konfiguration von »kdump« legt die Einstellungen zum Schreiben des Kernel-Dump fest. Dazu gehören der Ablageort, welche Informationen enthalten sind, optionale Komprimierung oder ein Aufsplitten des Dumps. Für die ersten Experimente empfiehlt es sich, mit der Standard-Einstellung zu beginnen.

Wesentlich für das Funktionieren der Kexec/Kdump-Methode ist, dass der Crash-Kernel zum Zeitpunkt des Problems bereits geladen ist. Dies übernimmt das Start-Skript von »kdump« , allerdings nur, wenn auch ein entsprechend geschützter Speicherbereich vorhanden ist. Damit der originale Kernel dies weiß, muss der Admin den Bootloader mit Option »crashkernel=XM[@YM]« versehen, wobei X die Größe des Reservierungsbereiches in MByte und Y die Start-Adresse angibt. Lässt man den zweiten Parameter weg oder gibt »0M« an, wählt das System automatisch einen geeigneten Platz aus.

Ein anschließender Neustart aktiviert diese Änderung.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite