Wenn das System einfriert ("freeze")...

RME · 8 Dez. 2011

Hallo,

Es kann bekanntlich vorkommen

dass ein System plötzlich einfriert und nicht mehr auf Tastatur oder Maus reagiert. Dann gibt es leider öfter nur noch die Methode, via Netzschalter "brutal" abzuschalten (oder den Reset-Knopf betätigen). Dies ist "brutal" vor allem weil die Festplatten so nicht ordnungsgemäss zuerst mit "umount" vor möglichem Schaden der Filesysteme geschützt werden.

Eine "Lösung" ist in solchen Fällen (sofern im Kernel implementiert) der "Magic SysRQ Key" -- ich möchte hier kurz darüber berichten und aber gleichzeitig Fragen ob diese Methode unbedenklich ist.

Zuerst die Methode:

Wenn das System eingefroren ist, folgende Tastenkombinationen in der gezeigten Reihenfolge eingeben:

Code:

Alt+PrntScreen+s
Alt+PrntScreen+u
Alt+PrntScreen+b

Je nach Tastatur Belegung ist "PrntScreen" == "SysRq" == "Druck/S-Abf"

Oder vielleicht funktioniert (wenn das root-Filesystem eingefroren ist):

Code:

Alt+PrntScreen+j

s = sync alle Filesysteme
u = remount alle Filesysteme read-only (nur lesen)
b = reboot

oder (die zweite Variante):

j = taut (unfreeze) ein eingefronenes Filesystem auf (mit "ioctl(fd, FITHAW, 0);")

Die erste Methode habe ich getestet... es scheint zu funktionieren. In der "/var/log/messages" Datei fand ich dann die (vermutlich relevanten) Zeilen:

Code:

# cat /var/log/messages
...
Dec  8 16:28:52 linux-ddia kernel: [ 6971.982345] SysRq : Emergency Sync
Dec  8 16:28:52 linux-ddia kernel: [ 6971.982696] Emergency Sync complete
Dec  8 16:28:58 linux-ddia kernel: [ 6977.150284] SysRq : Emergency Remount R/O
...

Hier noch ein paar Infos.:

Code:

> cat /etc/sysconfig/sysctl
...
...
## Path:        System/Kernel
## Description:
## Type:        string
#
# Magic SysRq Keys enable some control over the system even if it
# crashes (e.g. during kernel debugging).
#
# Possible values:
# - no: disable sysrq completely
# - yes: enable all functions of sysrq
# - bitmask of allowed sysrq functions:
#          2 - enable control of console logging level
#          4 - enable control of keyboard (SAK, unraw)
#          8 - enable debugging dumps of processes etc.
#         16 - enable sync command
#         32 - enable remount read-only
#         64 - enable signalling of processes (term, kill, oom-kill)
#        128 - allow reboot/poweroff
#        256 - allow nicing of all RT tasks
#
# For further information see /usr/src/linux/Documentation/sysrq.txt
#
ENABLE_SYSRQ="176"
>

Code:

> cat /proc/sys/kernel/sysrq
176
>

176 = 128 + 32 + 16

Code:

> cat /usr/src/linux/Documentation/sysrq.txt
(...Auszug...)
*  What is the magic SysRq key?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is a 'magical' key combo you can hit which the kernel will respond to
regardless of whatever else it is doing, unless it is completely locked up.

'b'     - Will immediately reboot the system without syncing or unmounting your disks.
'j'     - Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl.
'o'     - Will shut your system off (if configured and supported).
's'     - Will attempt to sync all mounted filesystems.
't'     - Will dump a list of current tasks and their information to your console.
'u'     - Will attempt to remount all mounted filesystems read-only.

re'B'oot is good when you're unable to shut down. But you should also 'S'ync
and 'U'mount first.

"'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen
(probably root) filesystem via the FIFREEZE ioctl.
>

Vielleichts interessierts? Wäre an Kommentaren (bez. Sicherheit etc. dieser Methode) interresiert.

Gruss,
Roland

Nachtrag: das "interessante" ist ja dass dies funktioniert ohne root-Rechte!!!

Anonymous · 8 Dez. 2011

RME schrieb:
Wäre an Kommentaren (bez. Sicherheit etc. dieser Methode) interresiert.

Da gibts nicht viel um über die Sicherheit nachzudenken. Wenn du dir bei einem Motorradunfall den Kopf abgerissen hast, ist es dann auch vollkommen Wurst das der einzige Arzt der den wieder richtig drauf nähen kann, regelmäßig 3 Tage die Woche stock-besoffen ist.

Denn du bist eigentlich tot und alles andere ist Zugabe, Zufall, oder was auch immer.

Beim Rechner ist das ähnlich, wenn der Kernel intern ein Problem sieht und darauf hin den Kernel stoppt, dann ist das die einzige Möglichkeit noch zu versuchen einen eventuellen Datenverlust so klein wie nur irgendwie möglich zu halten. Die Alternative ist eben nur ausschalten, und da können durchaus noch größere Mengen ungeschriebener Daten im Speicher sein. Wenn es nur irgendwelcher Multimedia-Werbungs-Mist ist der in den Browsercache geschrieben werden soll, ist das egal, ist es aber eine gut frequentierte Datenbank hast du eventuell nach dem hochfahren den einen oder anderen Datensatz für immer verloren, oder im schlimmsten Fall deine ganze Datenbank irreparable beschädigt.

Somit ist das eine schöne Geschichte und die Funktioniert auch oftmals, nur in der /var/log/messages wirst du nach einem Absturz nichts dazu finden, da laufen keinen Dienste mehr.

Meldungen dort sind bekommst du nur wenn der Kernel zu diesem Zeitpunt noch einwandfrei gelaufen ist.

Problem sind ein bisschen die Tasten. Da es hier ziemliche Unterschiede bei den Tastaturen gibt. Insbesondere bei manchen Minimal-Tastaturen ist in diesem Moment gar nicht mal so klar, was jetzt für einen Tastenkombination funktioniert, sollte man also vorher schon mal getestet haben. Eben so klar sollte vorher sein, ob das überhaupt aktiviert ist, oder mit Einschränkungen aktiviert ist.
Die Tastenkombination scheint ziemlich sicher vor versehendlichen Auslösen zu sein, ich hab es bei der normalen Arbeit noch nicht geschafft das unabsichtlich auszulösen, gehört habe ich das auch noch nicht.

Nächster Gedanke, das lässt sich ja nicht nur über diese Tastenkombination auslösen sondern, auch als user Root auf der Eingabzeile oder aus Scripten heraus, mit zB echo "s" > /proc/sysrq-trigger ob das dann immer noch auf jedem Rechner gewünscht ist? und das kann man wahrscheinlich nicht mal wirklich abschalten ohne einen neuen Kernel zu bauen, eventuell geht es aber geht auch abzuschalten per Bootoption, müsste ich auch erst nachsehen.

Nächster Gedanke, jeder der an die "richtige Konsole" dieses Rechners kommt, kann ohne Rootkennung den Rechner ausschalten, Solange die Konsole sich direkt neben dem Rechner befindet, ist das aber wiederum Wurst, weil da könnte er ja auch einfach den Ausschaltknopf dazu nehmen oder die Stromstecker ziehen. Und wer bis zum physikalischen Rechner vorstoßen kann, kann ja auch den ganzen Rechner einpacken und mitnehmen. Anders jedoch wenn es auch Möglichkeiten gibt, auf die Konsole Remote zuzugreifen. Wer sich dann hier her verirrt und sich nicht anmelden kann weil er das Passwort nicht kennt, schießt aus lauter Frust mit einer einzigen Tastenkombination eben den Rechner ab und bootet dann von unten her den Rechner komplett neu und gleich mit den Optionen, die er gerne hätte, um vollen Zugriff auf den Rechner zu haben. In solchen Rechnerumgebungen muss man sich etwas genauer überlegen ob man sowas haben will.

robi

RME · 8 Dez. 2011

Hallo Robi,

Danke für Deine Bemerkungen. Speziell der letzte Absatzt ist interessant...

Gruss,
Roland

Wenn das System einfriert ("freeze")...

RME

Advanced Hacker

Anonymous

Gast

RME

Advanced Hacker