Workshop: Open Source-Tipp

Mögliche Ursachen für Fehler in Applikationen sind meistens durch einen Blick in die entsprechende Logdatei der Anwendung schnell gefunden. Eine genaue Analyse ist mit Hilfe eines Coredumps möglich, der genaue Informationen der Umgebung zum Zeitpunkt des Fehlers enthält. Dazu gehören beispielsweise Prozessorregister-Informationen, ein Speicherabbild und andere hilfreiche Daten, mit denen sich Ursachenforschung betreiben lässt. Um diese Daten auszuwerten, kommt üblicherweise ein Debugger wie beispielsweise gdb zum Einsatz. Schwieriger wird es, wenn der Linux-Kernel selbst einen Fehler produziert. Hier sind zwei Fälle zu unterscheiden:

- Kernel-Oops: Hierbei handelt es sich um einen Fehler, der durch einen Exception Handler noch abgefangen werden kann. Diese Art von Fehlern treten beispielsweise bei ungültigen Zeigern auf. Die Fehlermeldung wird dabei in einer Logdatei hinterlegt, der aktuelle Prozess abgebrochen und das System läuft weiter.

- Kernel-Panic: In manchen Fällen ist der Kernel nicht in der Lage, das Problem selbst zu beheben. In einem solchen Fall sprechen wir von einer Kernel-Panic und es besteht keine Möglichkeit mehr, die gewünschten Informationen in einer Logdatei zu hinterlegen, da der Kernel einfach nicht mehr in der Lage ist, die hierfür notwendigen Operationen durchzuführen. Trotzdem bestehen Möglichkeiten, an die gewünschten Informationen heranzukommen, die wir im Folgenden betrachten.

Kdump und Kexec

Auf aktuellen Linux-Systemen, beispielsweise Red Hat Enterprise Linux 6 oder Fedora 20, kommt eine andere Methode zum Einsatz. Diese nennt sich kdump und besteht wieder aus zwei Komponenten. Das Tool kexec ist in der Lage, im Fehlerfall des Kernels einfach einen alternativen Kernel zu laden. Hierfür wird beim Systemstart ein bestimmter Speicherbereich auf dem System reserviert. Dieser alternative Kernel wird dabei sehr schnell geladen, da er das

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.