Absturzdiagnose unter Linux

Die Entzauberung der »S-Abf«-Taste und Neues vom Kernel

18. Juli 2024, 6:00 Uhr | Von Dr. Carsten Emde
© stock.adobe.com

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.

Diesen Artikel anhören

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.

passend zum Thema

Wozu dient eigentlich die »S-Abf«-Taste?

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.

Die System-Abfrage-Kommandos. *Diagnose, **Recovery
Die System-Abfrage-Kommandos. *Diagnose, **Recovery
© OSADL

Allerdings ist bei vielen Linux-Distributionen und Standardkonfigurationen die Systemabfrage nicht vorhanden. Der dafür erforderliche Quellcode muss erst noch durch die Kernel-Konfiguration

CONFIG_MAGIC_SYSRQ=y
 

bereitgestellt werden. Aber selbst dann ist die Funktion nach dem Booten des Systems nicht gleich aktiviert, sondern diese muss entweder manuell mit dem Kommando

echo 1 >/proc/sys/kernel/sysrq
 

individuell eingeschaltet oder in der Datei /etc/sysctl.conf mit dem Eintrag

kernel.sysrq = 1
 

automatisiert werden. Alternativ kann für die automatische Aktivierung die Kernel-Konfiguration

CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
 

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:

# echo s >/proc/sysrq-trigger
 

Wenn diese Funktion korrekt ausgeführt wurde, schreibt der Kernel

# dmesg | tail -2
[..] sysrq: Emergency Sync
[..] Emergency Sync complete

 

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

Rechte Alt-Taste plus SysRq plus S
Rechte Alt-Taste plus SysRq plus U
Rechte Alt-Taste plus SysRq plus B

 

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.

Im Fall des Falles

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

# echo 0x01020304 >/proc/sys/net/ipv4/icmp_echo_sysrq
 

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

# ping -c1 -s57 -p<pattern><ASCIIcommand> <hostname>
 

sodass die oben genannte S/U/B-Sequenz mit den drei Ping-Kommandos

# ping -c1 -s57 -p0102030473 <hostname> (0x73 = 'S')
# ping -c1 -s57 -p0102030475 <hostname> (0x75 = 'U')
# ping -c1 -s57 -p0102030462 <hostname> (0x62 = 'B')

 

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).

OSADL-Parport-Monitor für NMI-Polling
OSADL-Parport-Monitor für NMI-Polling.
© OSADL

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.


  1. Die Entzauberung der »S-Abf«-Taste und Neues vom Kernel
  2. Es fehlt noch ein robuster Ausgabekanal

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Open Source Automation Development Lab (OSADL) eG

Weitere Artikel zu Echtzeit-/Embedded Software

Weitere Artikel zu Software/Entwicklung

Weitere Artikel zu Embedded