Freeze protokollieren

minimike

Berufsrevolutionär
Hallo

Mittlerweile zum dritten Wochenende hintereinander ist heute ein FreeBSD-Server im Serverraum merkwürdig abgesemmelt. Ich bin jetzt deswegen extra in die Firma gefahren um das zu fixen
Das Merkwürdige Verhalten des Systems ist das der Server an sich weiterläuft. Er verliert aber die Konnektivität zum Netzwerk. Lokales Einloggen geht auch nicht. Man kann den Loginpromt sehen und sich anmelden jedoch friert der nach Passwortübergabe ein. In den Logs finde ich nicht jedoch nur das heute um 12:00 Uhr die letzten EInträge stattfanden. Die natürlich alle unverdächtig waren.
Was kann ich tun um da noch mehr Licht ins Dunkel zu bringen? Ich habe zwar Serverlast im Verdacht aber die kann in letzter Zeit so stark nicht gestiegen sein.

System ist FreeBSD 9.2 mit zwei XEON's und 96 GB Ram. Sowie 16x 3000 GB Platten im RaidZ. Das lief das ganze Jahr über recht geschmeidig. Auch mit einer Load von 50. Auf dem System läuft eine 100 GB starke PostgreSQL Datenbank für Bacula und Bacula als Director, Storage und FD. Zusätzlich Samba, Netatalk und NFS was aber am Wochende keine Clients hat.
 
Grundsätzlich klingt das nach blockierendem IO, also endloses Warten auf Zugriffe auf die Festplatten. Ich habe sowas schon öfter im Zusammenspiel mit unterschiedlichen RAID-Controllern (auch im Pass Through Mode) gesehen und wenn es debugbar war, lief es am Ende meist auf einem latent kaputten Controller oder eine defekte Firmware hinaus. Das festzunageln ist aber leider nicht einfach. Die einzig funktionierende Methode ist, den Kernel mit DDB (dem Online-Debugger) zu bauen und wenn es auftritt den Debugger direkt von der lokalen Konsole zu starten. Dann herumzustochern und schauen, ob man etwas findet. Es gibt zwar eine Debug-Sektion im Developers Handbook, leider ist sie aber für Entwickler geschrieben und daher erstmal recht abstrakt: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html
 
Kannst du über IPMI auf der Platform auch KVM Zugriff bekommen (i.d.R. über ein javabasiertes Verbrechen an der Menschheit)?
 
Kannst du über IPMI auf der Platform auch KVM Zugriff bekommen (i.d.R. über ein javabasiertes Verbrechen an der Menschheit)?
Nein ich kann nur auf dem Client ne Shell öffnen und via ipmitool remote an die lokale Shell des Servers
 
Hast du schon versucht einen Hardwarewatchdog zu konfigurieren um in den DDB zu kommen falls das System hängt? Mittels watchdogd -e cmd lässt sich ein beliebiges Script als Watchdogbedingung verwenden.
 
Wenn die SOL aus Sicht des Kernel eines normale serielle Schnittstelle ist, reicht es aus ein BREAK zu senden, um in den Debugger zu gelangen. Dazu muss allerdings "options BREAK_TO_DEBUGGER" im Kernel sein. Das kann allerdings gefährlich sein, da einige Clients für serielle Schnittstellen auch gern mal ungefragt BREAKs senden. Zum Beispiel beim Schließen der Verbindung.
 
Danke für die Antworten. War leider zu Spät. Der Server ist infernalisch abgeraucht. 25 TB Backups sind im Eimer. Aber ich habe nun gelernt die Katalogdatenbank in Zukunft im Cluster am Start zu Haben. Dann hätte ich wenigstens noch die Backups der Tapes gehabt.
 
Weis ich noch nicht. Ich habe erst einmal Bacula woanders installiert. Dann kann ich wenigsten Backups via Tape machen. Die Kiste bekomme ich diese Woche eh nicht mehr an den Start.
 
OK wenn du dann mit der Analyse fertig bist, würde es mich schon interessieren, was genau das Problem war :)
 
Back
Top