PANIC - falls der Rechner "spinnt"

Im folgenden einige Hinweise falls die Workstation nicht mehr auf Eingaben reagiert.

UNIX und Programmabstürze

Unter UNIX laufen in der Regel mehrere Programme als Prozesse gleichzeitig. So kann ein fehlerhaftes Programm das System lahmlegen, obwohl die anderen ihren Dienst problemlos verrichten könnten. Es muß deswegen nicht das gesamte System neugestartet werden, es genügt den Störenfried zur Ordnung zu bringen oder seine Abarbeitung zu beenden.
Meistens reagiert ein Programm auch wenn es sich in einer Endlosschleife befindet immer noch auf sogennannte Signale, mittels derer es in gewissen Maße gesteuert werden kann, z.B. zwingend beendet werden. Dazu mehr bei der Beschreibung des kill Befehles.

Der kill Befehl

Das Wichtigste in der Form einer Handbuchseite:
NAME
kill - beendet einen Prozeß
SYNTAX
kill [-Signummer] Prozeßnummer
BESCHREIBUNG
kill wird benutzt, um außer Kontrolle geratene ("aufgehängte") Prozesse, die sich nicht mehr auf normale Art beenden lassen, zu terminieren (beenden). kill sendet dazu das Signal Signalummer an den Prozezeß Prozeßnummer. Standardwert ist SIGTERM (15) zum terminieren des Prozesses. Es können aber auch beliebige andere Signale gesendet werden. Weil das Signal SIGTERM nicht von allen Programmen bearbeitet wird, wird ein Prozezeß manchmal erst mit dem Signal SIGKILL (9) vom Kernel beendet. Der "normalen" Terminierung mit SIGTERM ist aber der Vorzug zu geben, weil dadurch dem Prozezeß noch die Möglichkeit gegeben wird, die Bühne geordnet zu verlassen. Es können nur die eigenen Prozesse beendet werden.Statt der Signummer kann auch das entsprechende Kürzel verwendet werden(siehe kill -l).
Beispiel:
kill -KILL ist dasselbe wie kill -9
OPTIONEN -Signr sendet Signr anstelle von SIGTERM (15)

Wiederbelebung; Schritt für Schritt

  1. Andere freie Workstation suchen

    2. Möglichst in der Nähe der abgestürzten Maschiene und deren Monitor zur Überprüfung des Erfolges zum neuen Arbeitsplatz drehen.

  2. Einloggen

    3. Keine graphische Oberfläche starten, die einfache Textdarstellung ist ausreichend und absturzsicher. In bösen Fällen kann auch das fehlschlagen, Tips dazu in einem späteren Kapitel.

  3. Den Befehl hostname eingeben

    4. Nun ist bekannt, an welcher Maschiene man sich gerade eingeloggt hat, meist eeetw? .

  4. rusers - An welchen Computern wird gearbeitet

    5. Es wird eine Liste mit allen eingeloggten Nutzern ausgegeben. Wichtig sind nur die beiden Zeilen mit Ihrem Namen. Eine davon muß mit der Ausgabe von hostname übereinstimmen, diese ist uninteressant. Nun kann man die verklemmte Workstation direkt ansprechen, da ihr Name bekannt ist. Da das Programm rusers recht gründlich das Netzwerk nach Nutzern absucht, beendet sich erst nach ca. 2 Minuten. Solanges Warten ist nicht nötig, hat man die Information die man benötigt, mit Ctrl C abbrechen.

  5. rlogin [hostname] - Workstation "fernsteuern"

    6. hostname ist hier durch den bei 4. gefunden Namen zu ersetzen z.B. rlogin eeetwi. Für das hiesige Netzwerk ist an dieser Stelle wieder die Eingabe des Passworts nötig. Nun ist eine "Fernsteuerung" der verklemmten Maschiene möglich. Alle Befehle, die nun eingegeben werden, laufen auf dem scheinbar nicht mehr reagierenden Computer.

  6. ps - Liste der laufenden Programmeanzeigen

    7. Dazu nutzt man den Befehl ps. Für alle nötigen Informationen und eine lesbare Darstellung sollte man:
    ps -uxa|more oder, um nur seine eigene Programme zu sehen:
    ps -uxa|grep $LOGNAME|more eintippen.
    (Auf anderen UNIX-Versionen entsprechen die Optionen -ef den hier verwendeten -uxa)

  7. Prozessnummer des Übeltäters bestimmen

    8. Leichter gesagt als getan. Vielleicht war es das zuletzt gestartete Programm, vielleicht die graphische Oberfläche? Anzeichen für einen Absturz kann ein sehr hoher Verbrauch von Rechenleistung sein (Spalte %CPU bei >90%).
    Man kann entweder mit systematischen Probieren alle Programme stückweise beenden (siehe unten) oder durch Schliessen von OpenWindows oder der "login shell" radikal aufräumen. In UNIX werden die meisten Tasks von einer Shell oder anderen Task aus gestartet Die Tasks, von denen aus Programme gestartet wurden, bezeichnet man als Vaterprozesse. Wird ein Vaterprozeß beendet, so werden gleichzeitig die Kindprozesse terminiert. Bricht man also z.B. nur den Hauptprozeß der graphischen Oberfläche ab, führt das zur Beendigung aller auf OpenWindows laufenden Programme.
    Jedoch sollte man dabei VORSICHTIG!!!vorgehen.
    Zwar kann keine Hardware beschädigt, Daten gelöscht oder das Labor lahmgelegt werden, aber nichtgespeicherte Texte aus Editoren oder Simulationsläufen sind meist verloren. Besser ist es, nur das außer Kontrolle geratene Programm zu beenden (falls es bekannt ist).
    Wichtig ist es, in diesem Schritt die PID (Prozessnummer) herauszufinden. Die steht in der 2. Spalte der Ausgabe des Befehls ps -uxa. Als Beispiel: 
    USER          PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
root            1  0.7  2.8   48  208 con S    15:49   0:00 init auto
mueller        32  3.3  6.0  344  440 p 1 S    15:49   0:00 -tcsh
mueller        33  0.1  2.2   37  164 p 2 S    15:49   0:00 /sbin/agetty 38400 tt
root           18  0.2  3.2   57  232 con S    15:49   0:00 /usr/sbin/syslogd
mueller        14  0.0  0.9    5   68 con S    15:49   0:00 /sbin/update
mueller        20  0.1  2.8   36  204 con S    15:49   0:00 /usr/sbin/klogd
mueller        22  0.0  2.6   68  188 con S    15:49   0:00 /usr/sbin/lpd
mueller        24  0.0  2.9   85  212 con S    15:49   0:00 /usr/sbin/lpd
mueller        25  0.1  3.2   72  236 con S    15:49   0:00 /usr/sbin/crond
root           29  0.2  2.0   32  148 con S    15:49   0:00 selection -t ms
mueller        34  0.1  2.2   37  164 p 3 S    15:49   0:00 /sbin/agetty 38400 tt
mueller        35  0.1  2.2   37  164 p 4 S    15:49   0:00 /sbin/agetty 38400 tt
mueller        36  0.1  2.2   37  164 p 5 S    15:49   0:00 /sbin/agetty 38400 tt
mueller        37  0.1  2.2   37  164 p 6 S    15:49   0:00 /sbin/agetty 38400 tt
mueller        38  0.0  2.9   68  216 p 1 R    15:49   0:00 ps -uxa

    Vermutet man z.B. klogd als die Ursache, ist hier 20 die später wichtige Zahl. Die graphische Oberfläche ist mit xnews vertreten; die login shell ist die -csh mit der ältesten Startzeit. Mehr zu ps ist mit man ps in Erfahrung zu bringen.

  8. kill - Programm zwangsweise beenden

    9. Dazu wird der kill Befehl verwendet.Die Eingabe von kill [PID] beendet den problematischen Prozeß z.B> kill 20. Mit ps den Erfolg überprüfen. Ist der Prozeß wider Erwarten Stück immer noch vorhanden,wird er mit kill -KILL [PID] (z.B kill -KILL 20) sicher beendet. Mit kill -STOP [PID] wird dagegen nur versucht, den Task anzuhalten, um ihn später mit kill -CONT [PID] wieder zu starten . Aber das wird kaum einer wollen.
    Tasks anderer Nutzer können nicht beeinflusst werden. Sollten diese die Ursache sein, kann nur der Eigentümer des Prozesses oder ein Systemadministrator den Task beenden.Solche Situationen sind aber selten, da Programme anderer Nutzer, die im Hintergrund laufen, normalerweise keinen Zugriff auf Bildschirm und Tastatur haben und diese demzufolge auch nicht blockieren sollten. (In einigen UNIX Varianten reicht kill -TERM -1 aus, um alle Prozesse zu beenden.)

    Im Wechsel zwischen 7. und 8. sollte irgendwann der verursachende Prozeß terminiert sein. Anschliessend zweimal exit bzw. logout eingeben, (das erste Mal beendet die "Fernsteuerung", das zweite Mal die login shell), Monitor ausschalten, zum alten Platz wechseln etc..

    Es liest sich unter Umständen komplizierter als es ist. Auch habe ich die ausführliche Variante beschrieben, die sicher aufräumt, wo möglicherweise ein "sanfteres Vorgehen" , welches aber mehr Systemkenntnis voraussetzt, mehr Erfolg zeigt. Andere Nutzer nach Hilfe fragen, kostet nichts.

    BITTE schalten Sie unter gar keinen Umständen die Rechner ab (ausgenommen natürlich die Bildschirme). Falls Sie mit den hier beschriebenen Maßnahmen keinen Erfolg haben, belassen Sie den Computer in seinem Zustand und wenden sich an die Systemadministratoren oder den Schichtleiter.

Pannen der anderen Art


Stand: 06.12.94
Volker Urban
spinne@iee1.et.tu-dresden.de Kommentare,Vorschläge,Kritik und Fragen sind stets willkommen.