Notfall-Runbook fuer einen nicht reagierenden Server

1. Erste Klassifizierung: Netzwerk, Dienst oder Kernel?

Bevor ein nicht reagierender Server in Panik neu gestartet wird, lohnt sich eine schnelle Klassifizierung des Problems, weil die richtige Reaktion je nach Ursache vollstaendig unterschiedlich ausfaellt. Ein Server kann aus drei grundsaetzlich verschiedenen Gruenden nicht reagieren: ein reines Netzwerkproblem, bei dem der Server selbst gesund ist, aber nicht erreichbar; ein haengender Anwendungsdienst bei ansonsten funktionierendem Betriebssystem; oder ein tatsaechlich haengender Kernel, der auf keinerlei Eingaben mehr reagiert.

Diese Unterscheidung entscheidet, ob ein sanfter oder ein harter Eingriff angemessen ist. Ein nicht reagierender Server mit gesundem Kernel, aber haengendem SSH-Daemon laesst sich oft ueber alternative Zugriffswege retten, ohne Daten zu verlieren. Ein echter Kernel-Hang dagegen erfordert frueher oder spaeter einen Reset, aber selbst dann lohnt sich der Versuch, vorher noch moeglichst viele Diagnosedaten zu sichern.

In der Praxis hilft es, diese Klassifizierung als bewusste erste Frage im Team zu etablieren, statt sofort in hektische Einzelaktionen zu verfallen. Ein kurzer Moment der Einordnung spart bei einem nicht reagierenden Server haeufig mehr Zeit, als er kostet, weil er unnoetige Eskalationsschritte von vornherein ausschliesst.

Diese Klassifizierung sollte idealerweise nicht von einer einzelnen Person allein getroffen werden, sondern kurz im Team abgestimmt werden, um blinde Flecken zu vermeiden.

2. Schritt 1: Erreichbarkeit von aussen pruefen

Der erste Schritt bei jedem nicht reagierenden Server ist, von einem zweiten, unabhaengigen Standort aus die grundlegende Netzwerk-Erreichbarkeit zu testen, um ein reines lokales Problem des eigenen Arbeitsplatzes auszuschliessen. ping gegen die Server-IP und ein traceroute von einem anderen Netzwerk aus, etwa ueber einen Mobilfunk-Hotspot, zeigen schnell, ob das Problem tatsaechlich beim Server liegt oder nur an der eigenen Internetverbindung oder einem lokalen Firmennetzwerk-Ausfall.

Antwortet der Server auf ICMP, aber SSH auf Port 22 zeitigt keine Verbindung, deutet das auf einen haengenden oder abgestuerzten SSH-Daemon hin, waehrend der Kernel selbst noch funktioniert. Antwortet der Server auch nicht auf ICMP, aber der vorgelagerte Cloud-Provider zeigt die Instanz als laufend an, ist entweder der Netzwerk-Stack des Kernels blockiert oder es liegt tatsaechlich ein tieferes Kernel-Problem vor, das den Uebergang zum naechsten Schritt dieses Runbooks fuer den nicht reagierenden Server rechtfertigt.

Ein Blick in das Cloud-Provider-Dashboard oder die Hypervisor-Konsole liefert zusaetzlich Metriken wie CPU-Auslastung und Netzwerk-Durchsatz der letzten Minuten, unabhaengig vom Gastsystem selbst. Zeigt diese Aussenperspektive eine bei null verharrende CPU-Last, ist ein Kernel-Hang wahrscheinlicher als ein reines Anwendungsproblem des nicht reagierenden Servers.

Diese Metriken sollten idealerweise bereits vor dem Vorfall bekannt sein, damit ein Vergleich mit dem Normalzustand moeglich ist. Ein Team, das die typische Baseline eines Servers kennt, erkennt eine Abweichung bei einem nicht reagierenden Server deutlich schneller als eines, das die Werte zum ersten Mal waehrend des Vorfalls sieht.

3. Schritt 2: Alternative Zugriffswege statt Standard-SSH

Bevor ein nicht reagierender Server als vollstaendig verloren gilt, lohnt sich der Versuch alternativer Zugriffswege. Ein zweiter SSH-Versuch mit einem expliziten Timeout, etwa ssh -o ConnectTimeout=5 user@server, unterscheidet zwischen einem haengenden Verbindungsaufbau und einer sofortigen Ablehnung. Reagiert SSH gar nicht, aber der Server ist per Ping erreichbar, kann ein Blick auf andere offene Dienste helfen: Reagiert etwa noch ein Monitoring-Agent oder ein anderer TCP-Port, ist der Kernel vermutlich funktionsfaehig und nur der SSH-Daemon selbst haengt oder ist ueberlastet.

# Step 2: distinguish a hanging connection from an outright refusal
ssh -o ConnectTimeout=5 -o BatchMode=yes user@server "echo alive"
# ssh: connect to host server port 22: Connection timed out
# — server does not respond on port 22 at all, different from "Connection refused"

# Check if any other port is still responsive (e.g. monitoring agent)
nc -zv -w 3 server 9100

Ein besonders wertvoller, oft vergessener Zugriffsweg ist eine bereits bestehende, aber inaktive SSH-Sitzung auf demselben Server. Bleibt eine alte Terminal-Session unerwartet erreichbar, obwohl neue Verbindungen fehlschlagen, laesst sich darueber unter Umstaenden noch genug Diagnose durchfuehren, um die Ursache zu identifizieren, bevor der naechste, invasivere Schritt in diesem Runbook fuer den nicht reagierenden Server noetig wird.

In einer solchen verbliebenen Sitzung lohnt sich als Erstes ein schneller Blick mit uptime und free -h, um Load Average und Speicherbelegung zu erfassen, bevor die Sitzung moeglicherweise selbst einfriert. Diese wenigen Sekunden liefern oft die entscheidenden Datenpunkte fuer die spaetere Ursachenanalyse des nicht reagierenden Servers.

Auch ein zweiter, paralleler SSH-Login-Versuch von einem anderen Team-Mitglied kann sich lohnen, weil manche Verbindungsprobleme nur einzelne Client-IPs betreffen, etwa durch ein zu aggressives fail2ban-Regelwerk, das nach mehreren fehlgeschlagenen Versuchen faelschlich eine legitime IP sperrt statt tatsaechlich einen nicht reagierenden Server anzuzeigen.

4. Schritt 3: Out-of-Band-Zugriff ueber IPMI oder KVM

Scheitern alle Netzwerk-basierten Zugriffswege, ist Out-of-Band-Management der naechste Schritt fuer einen nicht reagierenden Server. Dedizierte Server verfuegen meist ueber IPMI oder iDRAC/iLO mit einem eigenen Netzwerk-Interface, das unabhaengig vom Hauptbetriebssystem laeuft und selbst bei einem vollstaendig haengenden Kernel weiterhin reagiert. Ueber eine serielle Konsole (ipmitool -I lanplus -H bmc-ip -U user sol activate) laesst sich der Bildschirminhalt live mitlesen, was oft sofort die Ursache zeigt, etwa eine Kernel-Panic-Meldung mit Stacktrace, die ueber SSH niemals sichtbar geworden waere.

Bei Cloud-Instanzen ersetzt die providereigene serielle Konsole (etwa die AWS EC2 Serial Console oder das Hetzner Cloud Console-Feature) das klassische IPMI und liefert denselben Wert: einen Blick auf den Bildschirm des Servers, unabhaengig vom Netzwerk-Stack. Dieser Schritt ist bei einem nicht reagierenden Server oft der entscheidende Moment, an dem aus Ratlosigkeit eine konkrete Diagnose wird, weil er die einzige Moeglichkeit ist, tatsaechlich zu sehen, was der Server gerade tut.

Wichtig ist, den Zugang zu dieser Konsole regelmaessig ausserhalb von Vorfaellen zu testen. Ein IPMI-Passwort, das seit der Erstinstallation nie wieder verwendet wurde, oder ein vergessenes Firmware-Update koennen genau in dem Moment zum Problem werden, in dem der Zugriff auf einen nicht reagierenden Server am dringendsten gebraucht wird.

Bei gemieteten Servern grosser Hosting-Anbieter ist der IPMI-Zugang oft ueber ein separates VPN oder eine IP-Whitelist abgesichert, was im Vorfeld eingerichtet und getestet werden muss. Ein nicht reagierender Server, dessen IPMI-Zugang erst waehrend des Vorfalls beantragt werden muss, verliert wertvolle Minuten durch Wartezeiten beim Support des Anbieters.

5. Schritt 4: Magic SysRq fuer einen kontrollierten Eingriff

Magic SysRq-Tasten erlauben direkte Kommandos an den Linux-Kernel, unabhaengig von Userspace-Prozessen, und sind damit oft die letzte Rettung vor einem nicht reagierenden Server bei einem vollstaendigen Neustart. Vorausgesetzt /proc/sys/kernel/sysrq war vorher aktiviert und Out-of-Band-Zugriff auf die Konsole besteht, liefert die Sequenz REISUB ein kontrolliertes Herunterfahren statt eines abrupten Stromausfalls: R (Tastatur wieder in Raw-Modus), E (alle Prozesse terminieren), I (alle Prozesse hart killen), S (Dateisysteme synchronisieren), U (schreibgeschuetzt remounten), B (Neustart).

# Enable SysRq beforehand (must be done in advance, not during an incident)
echo 1 > /proc/sys/kernel/sysrq

# During an incident, via serial console, trigger REISUB sequence:
# echo r > /proc/sysrq-trigger   # raw keyboard mode
# echo e > /proc/sysrq-trigger   # SIGTERM to all processes except init
# echo i > /proc/sysrq-trigger   # SIGKILL to all processes except init
# echo s > /proc/sysrq-trigger   # sync all filesystems
# echo u > /proc/sysrq-trigger   # remount all filesystems read-only
# echo b > /proc/sysrq-trigger   # immediate reboot

# Before REISUB, if kernel still responds: dump a call trace for later analysis
echo t > /proc/sysrq-trigger    # dump all task states to dmesg/console

# Optional: check current memory pressure before deciding on REISUB
echo m > /proc/sysrq-trigger    # dump current memory info to dmesg/console

Der entscheidende Vorteil von REISUB gegenueber einem harten Stromreset: Dateisysteme werden synchronisiert und schreibgeschuetzt gemountet, bevor der eigentliche Neustart erfolgt, was das Risiko einer Dateisystembeschaedigung erheblich reduziert. Reagiert der Kernel nicht einmal auf SysRq-Tasten, ist der Kernel selbst vollstaendig blockiert und ein nicht reagierender Server in diesem Zustand laesst sich nur noch durch einen Reset ueber die Out-of-Band-Schnittstelle beenden.

Zwischen den einzelnen Buchstaben von REISUB empfiehlt sich eine kurze Pause von ein bis zwei Sekunden, damit der Kernel jeden Schritt tatsaechlich abschliessen kann, bevor der naechste folgt. Wird die Sequenz zu schnell hintereinander ausgeloest, besteht das Risiko, dass Dateisysteme nicht vollstaendig synchronisiert werden, bevor der nicht reagierende Server neu startet.

Manche Distributionen deaktivieren SysRq standardmaessig teilweise ueber eine Bitmaske statt vollstaendig ueber 0 oder 1. echo 1 aktiviert alle Funktionen bedingungslos, waehrend feinere Bitmasken einzelne Funktionen wie den Reboot-Befehl separat steuern koennen, was bei der Vorbereitung eines Runbooks fuer einen nicht reagierenden Server beruecksichtigt werden sollte.

6. Schritt 5: Kernel-Panic- und OOM-Spuren nach dem Neustart

Nach dem Neustart eines vormals nicht reagierenden Servers ist die Ursachenanalyse genauso wichtig wie die Wiederherstellung selbst, um eine Wiederholung zu verhindern. journalctl -k -b -1 zeigt die Kernel-Logs des vorherigen Boots, also genau der Sitzung, die zum Ausfall fuehrte. Ein Kernel-Panic-Eintrag mit vollstaendigem Stacktrace zeigt oft direkt die verursachende Kernel-Komponente, etwa einen fehlerhaften Treiber oder ein Dateisystem-Problem.

Fehlt ein expliziter Panic-Eintrag, aber es finden sich Meldungen des OOM-Killers (Out of memory: Killed process), war vermutlich Speichererschoepfung die Ursache: Der Kernel toetet dann zwar einzelne Prozesse, kann dabei aber in einem Zustand haengen bleiben, der auch kritische Systemdienste wie sshd betrifft. dmesg -T | grep -i "killed process" nach dem Neustart zeigt genau, welcher Prozess dem OOM-Killer zum Opfer fiel und liefert damit einen konkreten Ansatzpunkt fuer die weitere Untersuchung.

Findet sich weder ein Panic-Eintrag noch ein OOM-Hinweis, lohnt ein Blick auf Hardware-bezogene Meldungen wie ECC-Speicherfehler oder Festplatten-I/O-Fehler kurz vor dem Ausfall. Ein nicht reagierender Server, dessen Kernel-Logs auf ein Hardwareproblem hindeuten, braucht eine grundlegend andere Nachbereitung als ein reines Softwareproblem.

Fehlen selbst diese Hinweise vollstaendig, weil die Kernel-Logs abrupt abbrechen, ist das selbst ein wichtiges Signal: Ein ploetzlicher, unkommentierter Abbruch ohne jede Vorwarnung deutet eher auf einen harten Hardware-Fehler oder eine externe Unterbrechung hin als auf ein von der Software verursachtes Problem des nicht reagierenden Servers.

7. Schritt 6: Der kontrollierte Reset als letztes Mittel

Reagiert weder SSH noch die Out-of-Band-Konsole noch Magic SysRq, bleibt fuer einen nicht reagierenden Server nur der harte Reset ueber die Power-Management-Schnittstelle des IPMI, des Cloud-Providers oder physisch vor Ort. Wichtig dabei: Vor dem Reset, sofern noch irgendein Zugriffsweg funktioniert, moeglichst viele Diagnosedaten sichern, etwa einen Screenshot der seriellen Konsole oder die letzten sichtbaren Kernel-Meldungen, weil diese Informationen nach dem Neustart oft unwiderruflich verloren sind.

Nach einem harten Reset ohne vorheriges REISUB besteht ein erhoehtes Risiko fuer Dateisystem-Inkonsistenzen, weshalb ein fsck-Lauf beim naechsten Boot haeufig automatisch ausgeloest wird und bei grossen Dateisystemen erhebliche Zeit in Anspruch nehmen kann. Diese Zeit sollte im Incident-Kommunikationsplan von vornherein eingeplant werden, damit Stakeholder nicht ueberrascht werden, wenn der nicht reagierende Server nach dem Reset noch weitere Minuten fuer die Dateisystempruefung braucht, bevor Dienste wieder starten.

Ein Reset per physischem Netzschalter sollte immer die allerletzte Eskalationsstufe bleiben, weil er im Gegensatz zum Power-Reset ueber IPMI keinerlei kontrollierte Signalisierung an das Betriebssystem sendet. Bei einem nicht reagierenden Server ohne jeglichen Fernzugriff bleibt dieser physische Eingriff jedoch manchmal die einzig verbliebene Option.

Nach jedem Reset sollte unmittelbar geprueft werden, ob alle abhaengigen Dienste tatsaechlich wieder korrekt gestartet sind, statt sich allein auf einen erfolgreichen Boot-Vorgang zu verlassen. Ein nicht reagierender Server, der zwar wieder bootet, bei dem aber ein einzelner kritischer Dienst den Start verpasst hat, wirkt fuer Monitoring-Systeme oft trotzdem als wiederhergestellt.

8. Nach dem Vorfall: Dokumentation und Nachbereitung

Jeder Vorfall mit einem nicht reagierenden Server sollte in einem strukturierten Post-Mortem festgehalten werden: Zeitpunkt des ersten Alarms, durchlaufene Eskalationsschritte, tatsaechliche Ursache laut Kernel-Logs, und die Zeit bis zur Wiederherstellung. Diese Dokumentation ist nicht nur fuer Compliance-Zwecke wichtig, sondern liefert die Grundlage, um das naechste Mal schneller zu reagieren, weil bereits bekannt ist, welcher Schritt in diesem Runbook typischerweise zum Erfolg fuehrt.

Besonders wertvoll ist die Frage, ob ein frueherer Eingriff das Problem haette verhindern koennen, etwa durch ein Speicher-Limit fuer einen bestimmten Dienst, ein aktiviertes Watchdog-Modul oder ein frueheres Monitoring-Alarming bei steigendem Speicherdruck. Ein nicht reagierender Server, dessen Ursache identifiziert und behoben wurde, ist ein deutlich geringeres Risiko als derselbe Vorfall, der sich unter identischen Bedingungen jederzeit wiederholen kann.

Ein kurzes, aber verbindliches Nachbereitungstreffen innerhalb weniger Tage nach dem Vorfall stellt sicher, dass die identifizierten Massnahmen tatsaechlich umgesetzt werden, statt in einem Ticket zu versanden. Gerade bei einem nicht reagierenden Server, der ein kritisches System betraf, rechtfertigt der potenzielle Schaden eines wiederholten Ausfalls diesen zusaetzlichen organisatorischen Aufwand.

Die Dokumentation sollte auch fuer Kolleginnen und Kollegen lesbar sein, die beim urspruenglichen Vorfall nicht dabei waren. Ein knapper, aber vollstaendiger Bericht ueber einen nicht reagierenden Server ist im naechsten aehnlichen Fall wertvoller als eine luckenhafte Notiz, die nur der urspruengliche Bearbeiter versteht.

9. Praevention: Was jeder Server vorher haben sollte

Die effektivste Massnahme gegen einen nicht reagierenden Server ist Vorbereitung, lange bevor der Vorfall eintritt. echo 1 > /proc/sys/kernel/sysrq dauerhaft ueber /etc/sysctl.d/ konfiguriert, ein funktionierender und regelmaessig getesteter Zugang zu IPMI oder der Cloud-Provider-Konsole, sowie ein dokumentiertes Passwort- und Zugriffskonzept fuer den Notfall gehoeren zur Grundausstattung jedes produktiven Servers.

Ein Kernel-Watchdog (softdog-Modul oder Hardware-Watchdog) kann bei einem echten Kernel-Hang automatisch einen Neustart ausloesen, ohne auf menschliches Eingreifen zu warten, was die Ausfallzeit bei einem nicht reagierenden Server drastisch reduziert. In Kombination mit Alerting, das nicht nur Anwendungsmetriken, sondern auch die grundlegende Erreichbarkeit des Servers selbst ueberwacht, verkuerzt sich die Zeit von Ausfallbeginn bis zur ersten Reaktion oft von Stunden auf Minuten.

Ein regelmaessiger, geplanter Testlauf des gesamten Runbooks, etwa halbjaehrlich in einem Wartungsfenster, deckt veraltete Zugangsdaten oder nicht mehr funktionierende IPMI-Firmware auf, bevor ein echter nicht reagierender Server den Ernstfall darstellt. Diese Uebung kostet wenig Zeit, verhindert aber, dass sich das Team im Vorfall zum ersten Mal mit einer unbekannten Oberflaeche auseinandersetzen muss.

Diese Vorbereitung ist keine einmalige Aufgabe, sondern muss bei jedem neuen Server im Bestand wiederholt werden. Ein einzelner vergessener Host ohne getesteten IPMI-Zugang reicht aus, damit aus einem gewoehnlichen nicht reagierenden Server ein tagelanger Ausfall wird.

Diese fuenf Eskalationsstufen bilden das Rueckgrat des Runbooks fuer einen nicht reagierenden Server: Jede Stufe wird erst dann verlassen, wenn die vorherige nachweislich keinen Erfolg gebracht hat, wodurch das Risiko einer Dateisystembeschaedigung oder eines Datenverlusts so lange wie moeglich minimiert bleibt.

In einem gut vorbereiteten Team dauert der Durchlauf durch die ersten drei, risikofreien Stufen selten laenger als fuenf bis zehn Minuten. Die eigentliche Zeit geht meist bei der Entscheidung verloren, ob und wann zur naechsten, invasiveren Stufe gewechselt wird, weshalb klare, vorab vereinbarte Kriterien fuer jeden Uebergang den Umgang mit einem nicht reagierenden Server erheblich beschleunigen.

10. Zusammenfassung

Ein nicht reagierender Server verlangt eine klare, vorab definierte Eskalationsreihenfolge statt einer Panikreaktion: erst Netzwerk-Erreichbarkeit von einem zweiten Standort pruefen, dann alternative Zugriffswege testen, dann Out-of-Band-Zugriff ueber IPMI oder die Cloud-Provider-Konsole nutzen, dann Magic SysRq mit REISUB fuer ein kontrolliertes Herunterfahren versuchen, und erst als allerletztes Mittel einen harten Reset ausloesen.

Nach der Wiederherstellung entscheidet die Analyse der Kernel-Logs aus dem vorherigen Boot, ob eine Kernel-Panic, Speichererschoepfung oder ein anderer Grund die Ursache war. Wer diese Reihenfolge vorab dokumentiert und die notwendigen Zugriffswege wie IPMI und SysRq im Vorfeld einrichtet, verwandelt einen potenziell stundenlangen Ausfall eines nicht reagierenden Servers in einen Vorfall, der innerhalb weniger Minuten kontrolliert geloest wird.

Am Ende zaehlt weniger das einzelne Werkzeug als die Disziplin, jede Eskalationsstufe tatsaechlich zu durchlaufen, bevor auf die naechste, invasivere Massnahme zurueckgegriffen wird. Genau diese Disziplin unterscheidet ein professionell betreutes Serverumfeld von einem, in dem jeder Vorfall mit einem nicht reagierenden Server erneut zur improvisierten Ausnahmesituation wird.

Ein einmal erarbeitetes und regelmaessig getestetes Runbook zahlt sich beim naechsten Vorfall unmittelbar aus, unabhaengig davon, wer im Team gerade Dienst hat.

11. FAQ: Nicht reagierender Server