Mit dem »Absturz« eines Computers ist nicht alles aus. Es gibt Hardwareeinheiten, die weiterhin funktionieren. Diese kann man nutzen, um der Absturzursache auf den Grund zu gehen.
Früher oder später gerät vermutlich jedes Betriebssystem in eine Situation, in der es zum »Absturz« des Computers kommt. Dann hätte man gern eine Blackbox, um zu erfahren, was zuletzt vorgefallen ist. Dies mag in der aktuellen Situation nicht viel helfen, aber diese Information enthält in der Regel den Schlüssel, um das Problem zu beheben. Es muss also – zumindest in der Entwicklungsphase eines Computers und speziell eines Embedded-Systems – alles dafür getan werden, dass eine Blackbox die letzten Meldungen vor dem Absturz eines Computers aufzeichnet und abspeichert. Dafür muss erstens gewährleistet sein, dass sich die Ausgabe von diagnostischen Informationen triggern lässt, und zweitens, dass ein robuster Ausgabekanal zur Verfügung steht, der trotz Absturz noch funktioniert. Als Trigger dient eine spezielle, bisher nur wenig bekannte Abfragefunktion, und ein geeigneter robuster Ausgabekanal wird zur Zeit gerade in den Linux-Kernel eingebracht.
Bei gleichzeitiger Betätigung der rechten Alt-Taste und der »Druck«-Taste kann man durch zusätzliches Betätigen einer weiteren Buchstaben- oder Zifferntaste ein internes Kernel-Kommando zur Systemabfrage auslösen. Daher ist auf vielen deutschen Tastaturen die »Druck«-Taste zusätzlich mit »S-Abf« beschriftet. Bei der ASCII-Tastatur steht auf der entsprechenden Taste in der ersten Zeile »Prt Scrn« für »Print Screen« und darunter »SysRq« für »System Request«. Die Tabelle enthält die wesentlichen Kommandos dieser Systemabfrage.
Allerdings ist bei vielen Linux-Distributionen und Standardkonfigurationen die Systemabfrage nicht vorhanden. Der dafür erforderliche Quellcode muss erst noch durch die Kernel-Konfiguration
bereitgestellt werden. Aber selbst dann ist die Funktion nach dem Booten des Systems nicht gleich aktiviert, sondern diese muss entweder manuell mit dem Kommando
individuell eingeschaltet oder in der Datei /etc/sysctl.conf mit dem Eintrag
automatisiert werden. Alternativ kann für die automatische Aktivierung die Kernel-Konfiguration
verwendet werden. Um sicherzustellen, dass die System-Abfrage im Notfall tatsächlich funktioniert, kann man ein Kommando in die Kernel-Variable /proc/sysrq-trigger schreiben. Dies kann zum Beispiel mit dem Sync-Kommando erfolgen:
Wenn diese Funktion korrekt ausgeführt wurde, schreibt der Kernel
in die Logdatei. Die Trigger-Variable /proc/sysrq-trigger ist allerdings im Falle eines Computerabsturzes normalerweise nicht verwendbar, weil ein Log-in mit Shell-Kommandozeile nicht mehr funktionsfähig ist. Die Systemabfrage über das Keyboard ist dagegen häufig noch möglich, sodass sich zum Beispiel ein gezielter Reboot des Systems mit der Kommando-Sequenz S/U/B auslösen lässt. Durch die Sync- und Unmount-Kommandos vor dem Reboot wird mit hoher Wahrscheinlichkeit verhindert, dass beim Reboot ein Filesystem-Check ausgeführt wird. Für diese Kommando-Sequenz müssen nacheinander die Tasten
betätigt werden. Aber eigentlich will man dies gerade nicht, weil die wichtige Information über die Ursache des Absturzes dann unwiederbringlich verloren ist. In jedem Fall sollte ein Ausgabekanal verfügbar sein, der die letzten Meldungen vor dem Absturz aufgefangen und gespeichert hat.
Es sollte versucht werden, mit der Systemabfrage zum Beispiel den Status der Tasks und die Backtraces der CPUs auszugeben, um den Absturz rekonstruieren zu können.
Was tun, wenn die Tastatur nicht mehr funktioniert?
In diesem Fall kann es sein, dass die Netzwerkkommunikation über ICMP noch funktioniert, sodass ein von OSADL bereitgestellter Kernel-Patch zur Anwendung kommen kann [1]. Wenn dieser Patch angewandt wurde, steht die Kernel-Variable /proc/sys/net/ipv4/icmp_echo_sysrq zur Verfügung, in die ein bestimmtes Byte-Muster hineingeschrieben werden kann wie zum Beispiel
Erst dadurch wird Ping-SysRq aktiviert und ein entsprechend gestaltetes Ping-Netzwerk-Paket kann am lokalen System die jeweilige Systemabfrage auslösen. Die Syntax des Ping-Aufrufs lautet
sodass die oben genannte S/U/B-Sequenz mit den drei Ping-Kommandos
ausgelöst werden kann. Es versteht sich von selbst, dass diese Funktion nur für die Entwicklung gedacht ist und natürlich niemals bei Produktivsystemen eingesetzt werden darf.
Was tun, wenn auch das Netzwerk nicht mehr funktioniert?
In diesem Fall könnte es sein, dass das Computer-Board über einen Watchdog verfügt, der entsprechend programmiert worden sein könnte, damit beim Ausbleiben einer zyklischen Schreiboperation auf ein Watchdog-Register eine Systemabfrage ausgelöst wird. Die genaue Vorgehensweise hängt vom individuell vorhandenen Watchdog-Chip ab, sodass hier keine weiteren Informationen gegeben werden können.
Was tun, wenn das Board nicht über einen Wachdog verfügt?
In diesem Fall könnte es hilfreich sein, wenn der Computer über eine parallele IEEE-1284-Druckerschnittstelle verfügt (oder über ähnliche GPIO-Leitungen), denn diese können verwendet werden, um Controller-Register durch direkten Speicherzugriff zu lesen oder zu schreiben, ohne dass Interrupt-Bearbeitung erforderlich ist. Dies ist wichtig, da das Interrupt-System im Falle eines Absturzes möglicherweise nicht mehr funktioniert. Obwohl diese heute nicht mehr zum Anschluss eines Druckers verwendet werden, sind Parallelport-Adapter für den PCI-, PCIe- und Mini-PCIe-Bus immer noch weit verbreitet und werden von Linux unterstützt. OSADL stellt ebenfalls im Rahmen der Add-on-Patches einen kleinen Kernel-Treiber bereit [2] und liefert dafür einen Adapter mit acht Leuchtdioden und vier Drucktastern (siehe Bild).
Mithilfe dieses Adapters und dem genannten Treiber lassen sich über ein NMI-Callback (Non Maskable Interrupt) die Stellungen der Drucktaster abfragen und entsprechende Systemabfragen auslösen. Dabei muss beachtet werden, dass die Tasten jeweils so lange gehalten werden müssen, bis ein NMI getriggert wird. Dafür können die Leuchtdioden so programmiert werden, dass diese die Anzahl an NMIs anzeigen und auf diese Weise das Auftreten eines NMI erkannt werden kann. Diese Methode, das Auftreten eines internen Events als Trigger zu verwenden, ermöglicht es, selbst dann noch eine Systemabfrage zu triggern, wenn kein einziger externer Eingabekanal mehr funktioniert.