Absturzdiagnose unter Linux
Die Entzauberung der »S-Abf«-Taste und Neues vom Kernel
Fortsetzung des Artikels von Teil 1
Es fehlt noch ein robuster Ausgabekanal
Die genanten Methoden, kurz vor bzw. nach einem Computerabsturz einen internen Trigger auszulösen, mit dem wichtige Systeminformationen bereitgestellt werden, sind vollkommen sinnlos, wenn der Computer zu diesem Zeitpunkt nicht mehr in der Lage ist, diese Informationen auszugeben oder dauerhaft abzuspeichern. Eine solche weitgehend eingeschränkte Funktionalität betrifft häufig Filesystem-Operationen und Plattenzugriffe, USB-Subsystem, transparenten Dateizugriff über Netzwerk und andere mit Interrupt betriebene Peripheriegeräte. Verfügbar ist in der Regel nur noch die klassische serielle RS-232-Verbindung, die allerdings bereits vorher konfiguriert sein muss. Üblicherweise erfolgt dies in der Kernel-Kommandozeile zum Beispiel für die Schnittstelle /dev/ttyS0 mit
earlyprintk=ttyS0,115200 console=ttyS0,11520
und
ignore_loglevel systemd.getty_auto=false
wobei mit den beiden letzten Kommandos verhindert wird, dass ein zu geringer Loglevel eingestellt wird bzw. systemd eine Login-Konsole startet, was möglicherweise mit der Ausgabefunktion interferiert. Als nächstes stellt sich nun die Frage, was mit der Textinformation geschieht, die über die serielle Schnittstelle ausgegeben wird. Sicher ist es nicht sinnvoll, ein Terminal daran anzuschließen, denn die Information ist in der Regel viel länger, als dass sie auf eine Bildschirmseite passt. Hinzu kommt, dass der zuerst ausgegebene Text die relevante Information enthält, die benötigt wird, um die Absturzursache zu analysieren, während am Ende des Textes häufig nur irrelevante Folgefehler dokumentiert werden. Es muss also in jedem Fall dafür gesorgt werden, dass die gesamte Textausgabe dauerhaft gespeichert wird. Eine Möglichkeit besteht darin, einen zweiten Computer mit der seriellen Schnittstelle zu verbinden und dort ein Programm zur Terminal-Emulation mit Protokollfunktion laufen zu lassen. Dafür bietet sich Minicom an, das mit der Umgebungsvariable
export MINICOM="-C /root/minicom.cap"
betrieben wird, was dazu führt, dass der gesamte Datenverkehr in der angegebenen Datei dauerhaft gespeichert wird. Alternativ kann ein serieller Netzwerkadapter verwendet werden, der in der Lage ist, den Datenverkehr über Netzwerk zum Beispiel auf einem NFS-Mount abzulegen.
Jobangebote+ passend zum Thema
Krisensichere Ausgabefunktion des Linux-Kernels
Der Linux-Kernel verfügt praktisch schon von Anfang an über die Ausgabefunktion printk(), die auch von der System-Abfrage genutzt wird. Nachteil der bisherigen Implementation ist aber, dass diese Funktion in der gleichen Kernel-Task weiterläuft, aus der sie aufgerufen wurde, der Kernel sich aber in einem Zustand befinden kann, in dem der Aufruf einer Schreibfunktion eines Peripheriegerätes gar nicht möglich ist. Dies betrifft zum Beispiel bestimmte Locking-Szenarien oder Bearbeitung von Ausnahme-Situationen. Die printk()-Funktion spielt auch eine wesentliche Rolle bei der Entwicklung der sogenannten PREEMPT_RT-Patches, mit denen der Linux-Kernel echtzeitfähig gemacht werden kann. Denn bisher war ein Workaround für die printk()-Funktion erforderlich, um die damit verbundenen Latenzen zu vermeiden.
Auf der anderen Seite haben die Kernel-Entwickler es abgelehnt, diesen Workaround in den Hauptentwicklerzweig des Linux-Kernels aufzunehmen, sodass eine komplette Neuimplementierung der printk()-Funktion erforderlich wurde, damit die PREEMPT_RT-Patches eines Tages ebenfalls komplett in den Hauptentwicklerzweig aufgenommen werden können. Bei dieser Neuimplementierung wird für die Ausgabe von Kernel-Meldungen ein getrennter und unabhängiger Thread gestartet, sodass es keine Einschränkungen mehr gibt, aus welchem Kontext der Aufruf erfolgt. Außerdem ist damit die uneingeschränkte Kompatibilität mit den Echtzeitanforderungen gewährleistet.
Als gewisser Nachteil ist allerdings anzumerken, dass für die Neuimplementierung alle seriellen Treiber mit einer zusätzlichen Funktionalität ausgestattet werden müssen, sodass es noch eine Weile dauern könnte, bis die neue printk()-Funktion auf der gesamten unterstützten Hardware und von allen Architekturen genutzt werden kann. Im ersten Schritt wird nur der klassische 8250-basierte UART unterstützt. Aber diese Implementierung kann als Muster verwendet werden, um die anderen Treiber nachzuziehen, und erste Aktivitäten in dieser Richtung erfolgen bereits.
Wie kann man feststellen, dass die neue printk()-Funktionalität wirksam ist? Voraussetzung ist das Vorhandensein eines Kernel-Threads mit dem Prefix pr/ und gefolgt vom Namen des konfigurierten seriellen Gerätes. Der in jedem Fall vorhandene Kernel-Thread pr/legacy emuliert nur die bisherige Funktionalität. Im ersten Schritt sollte man also überprüfen, welche dieser Kernel-Threads vorhanden sind:
# ps ax | grep pr/ | grep -v grep
17 ? S< 0:00 [pr/legacy]
269 ? S< 0:41 [pr/ttyS0]
Hier ist pr/ttyS0 vorhanden, sodass eine wichtige Voraussetzung für die neue printk()-Funktion erfüllt ist. Darüber hinaus enthält die Kernel-Variable /proc/console das neue Symbol N, womit das Vorhandensein einer nichtblockierenden Konsole angezeigt wird:
# cat /proc/consoles
tty0 -WU (EC ) 4:2
ttyS0 -W- (E Np a) 4:68
Was bedeutet dies für die lange erwartete Aufnahme der PREEMPT_RT-Patches in den Hauptentwicklerzweig des Linux-Kernels?
Da die PREEMPT_RT-Patches im Wesentlichen nur noch aus der printk()-Reimplementierung bestehen, ist davon auszugehen, dass mit deren vollständiger Aufnahme in den Hauptentwicklerzweig des Linux-Kernels dies auch für die PREEMPT_RT-Patches gilt und von diesem Zeitpunkt an der direkt vom Server kernel.org erhältliche Linux-Kernel durch einfache Konfiguration in einen Echtzeit-Kernel verwandelt werden kann. Da die ersten Überlegungen, Konzepte und Teilimplementierungen für diese Echtzeitfähigkeit auf die Zeit vor dem Jahr 2000 zurückgehen, hätte dann nach einer über 25 Jahre gehenden wechselvollen Geschichte ein maximal anspruchsvolles Softwareprojekt sein Etappenziel erreicht.
Referenzen
[1] OSADL Add-on-Patch Ping-SysRq, https://www.osadl.org/?id=2944
[2] OSADL Add-on-Patch NMI-SysRq, https://www.osadl.org/?id=2946
Der Autor
Dr. Carsten Emde
blickt auf eine langjährige berufliche Tätigkeit in den Bereichen Softwareentwicklung, Systemintegration und Schulung zurück, insbesondere für eingebettete Systemsoftware. Er ist spezialisiert auf grafische Benutzeroberflächen, Robotik, Echtzeitsysteme und auf rechtliche und geschäftliche Aspekte des Einsatzes von Open-Source-Software in der Industrie. Er leitet das Open Source Automation Development Lab (OSADL) seit dessen Gründung im Jahr 2005.
- Die Entzauberung der »S-Abf«-Taste und Neues vom Kernel
- Es fehlt noch ein robuster Ausgabekanal
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
