Das Debuggen der Linux-Maschine friert ein

Ich habe 15 identische 64-Bit-Server für Linux RH 4.7. Sie führen eine Clusterdatenbank aus (Cluster ist Anwendungsebene). Gelegentlich (jeden Monat oder so) friert eine zufällige Box (allerdings nie dieselbe) ein.

Ich kann die Box pingen und Ping funktioniert. Wenn ich versuche, in der Box zu ssh, bekomme ich:

ssh_exchange_identification: Connection closed by remote host

SSH ist ordnungsgemäß eingerichtet.

Wenn ich in den Serverraum gehe und versuche, mich direkt bei der Konsole anzumelden, kann ich die Konsole mit Alt+ wechseln Fn, einen Benutzernamen eingeben und Zeichen werden angezeigt, aber nach dem Drücken Enterpassiert nichts. Ich habe einmal 8 Stunden gewartet und es hat sich nicht geändert.

Ich habe syslog eingerichtet, um alles auf einem Remote-Host zu protokollieren, und diese Protokolle enthalten nichts. Wenn ich den Computer neu starte, funktioniert es ohne Probleme. Ich habe HW-Tests durchgeführt - alles ist in Ordnung und nichts ist in den Protokollen. Die Maschinen werden auch mit NAGIOS überwacht, und es gibt keine ungewöhnliche Belastung oder Aktivität vor dem Einfrieren.

Ich habe keine Ideen mehr; Was kann ich noch tun oder überprüfen?

Es hört sich so an, als wäre Ihr Kernel in Panik geraten, sodass sshd die Serverschlüssel nicht senden konnte. Möglicherweise war der Kernel so eingeklemmt, dass der Netzwerkstapel noch aktiv war, die vfs-Schicht jedoch nicht verfügbar war.

Wenn auf einem RHEL4-System ähnliche Probleme auftraten, richtete ich die Dienste netdump und netconsole sowie einen dedizierten Netdump- und Syslog-Server ein, um die Crash-Dumps und Kernel- Panikinformationen abzufangen . Ich habe auch die Datei kernel.panic sysctl auf 10 gesetzt. Auf diese Weise erhalten Sie bei Panik eines Systems sowohl die Kernel-Ablaufverfolgung als auch eine Kopie des Speichers auf diesem System, die Sie mit dem Dienstprogramm 'crash' analysieren können.

Sie würden sicherlich auch davon profitieren, eine serielle Konsole für die Hosts einzurichten, damit Sie sehen können, wie die Konsole ausgegeben wird und möglicherweise die magischen sysrq-Tasten drücken. Wenn Sie bereit sind, das Netzwerk einzurichten, und über Hardware verfügen, die dies unterstützt, können Sie IPMI verwenden, um die Hardware aus der Ferne auszuschalten, einzuschalten, neu zu starten und abzufragen.

(RHEL5 hat eine ähnliche Funktionalität wie kexec / kdump, nur der Crash-Dump wird lokal gespeichert.)

Ich werde Dollar auf Donuts wetten, dass Ihnen der Speicher ausgeht. Das System kommt zum Stillstand, als es versucht herauszufinden, woher es welche hat. Es kann so schnell gehen, dass Ihre Überwachung es nicht erfasst. Ich würde die Überwachung verstärken, einschließlich der Remote-Protokollierung der Speichernutzung. Überprüfen Sie die Protokolle auch auf OOM-Nachrichten.

(Vielleicht möchten Sie sogar nur einige SSH-Fenster öffnen, die oben laufen.)

Für mich klingt dies so, als ob das System keine Ressourcen mehr hat, sodass der von der Serverseite von ssh benötigte Prozess nicht zugewiesen werden kann.

Der tatsächliche Engpass kann variieren - aus Prozessen oder aus dem Speicher heraus - und der einzige Weg, um sicher zu sein, besteht darin, die Protokolle und die Konsole zu überprüfen, um festzustellen, ob dort etwas vorhanden ist. Möglicherweise möchten Sie ein Szenario mit vorgestarteten SSH-Jobs einrichten - eines für jeden Computer -, um es beim nächsten Mal einfach vorzubereiten.

Wenn es wirklich schlecht ist, sollten Sie eine andere Shell mit mehr integrierten Befehlen starten, damit Sie mehr Nachforschungen anstellen können, ohne einen zusätzlichen Prozess starten zu müssen, da dies möglicherweise nicht möglich ist. Auch "tail -f / var / log / *" kann sehr nützlich sein.

Viel Glück.

Das einzige Mal, dass ich etwas Ähnliches gesehen habe, war, wo ein KVM-Switch verwendet wurde und ein Tastatur-Hotkey (z. B. alt + n) zum Umschalten zwischen Servern verwendet wurde. Es passierte nicht jedes Mal und es war der Server, von dem weggeschaltet wurde, der betroffen war - also war es nicht sofort bemerkbar. Es würden keine Abstürze auftreten, wenn eine physische Schaltfläche am KVM-Switch selbst zum Wechseln zwischen Servern verwendet würde. Wenn der Hotkey häufig verwendet wurde, erlaubte ein Server gelegentlich keine neuen Anmeldungen. Bestehende SSH-Sitzungen waren nicht betroffen.