• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Unmotivierte Systemabstürze (CentOS)

gehrke

Administrator
Teammitglied
Moin *,

ich scheine hier ein fieses Problem mit Abstürzen auf meinem Server (CentOS 6.2) zu bekommen. Heute zum zweiten Mal in einer Woche fehlen jegliche Netzwerkdienste und bei der lokalen Anmeldung lande ich in einer rudimentären Umgebung (busybox?). Siehe Screenshot:
ymiYvy.jpg


1L3JHv.jpg

Als es beim bisher einzigen Mal zuvor passiert ist, habe ich das System neu gebootet und in den Logs nach Fehlern/Hinweisen gesucht, bin aber nicht fündig geworden. Der letzte Eintrag war ein beliebiger DHCP-Eintrag, erst Stunden später dann etwas vom Reboot. Details habe ich in meinem Wiki vermerkt, dass ist aber auch auf dem Server und der ist derzeit kaputt.

Es handelt sich um einen Server von 2011 mit CentOS 6.2. Bislang machte die Hardware keine Probleme im 24x7-Betrieb.

Konfiguration:
md0: RAID1 (md-adm) für /boot
md1: RAID6 mit 6 Disks (md-adm)

Letzte bekannte Aktivität war ein Full-Backup als Bacula-Server innerhalb eine VM (KVM) über mehrere Tage, also hohe Last.

Derzeit befindet sich das System noch in diesem Zustand. Ich vermute, dass ich kaum mehr relevante Informationen nach einem Reboot bekommen werde. Kann ich jetzt noch etwas aus diesem Systemzustand herauskitzeln, bevor ich durchstarte???
TNX

cu, gehrke
 

marce

Guru
Die Fehlerbeschreibung deutet auf defekte Hardware (ich tippe auf Speicher, Netzteil oder CPU / Board - in der Reihenfolge) hin.
 

josef-wien

Ultimate Guru
gehrke schrieb:
fehlen jegliche Netzwerkdienste
gehrke schrieb:
Screenshot: unable to mount rootfs
Das ist für mich ein Widerspruch. Nachdem ich /dev/mapper/... sehe, muß übrigens mehr als mdadm im Spiel sein.

Ohne Systempartition gibt es keine Log-Dateien. Falls dmesg in der initrd enthalten ist, sehe ich das als einzige Chance.

gehrke schrieb:
Unmotivierte Systemabstürze
Da könnte marce richtig liegen.
 
OP
gehrke

gehrke

Administrator
Teammitglied
@marce: Woran erkennst Du das???
Bei den FS-Checks vermute ich, dass es Inkonsistenzen infolge des Absturzes gibt. Aber die Ursache?
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
gehrke schrieb:
fehlen jegliche Netzwerkdienste
gehrke schrieb:
Screenshot: unable to mount rootfs
Das ist für mich ein Widerspruch. Nachdem ich /dev/mapper/... sehe, muß übrigens mehr als mdadm im Spiel sein.
Inwiefern ein Widerspruch?

Ja, da ist mehr dahinter. Auf dem RAID md1 liegt ein LUKS-Container und darin eine LVM-Partitionierung. Das habe ich in der ersten Beschreibung nicht für relevant gehalten, weil schon das RAID nicht gefunden wird.
 

marce

Guru
gehrke schrieb:
@marce: Woran erkennst Du das???
Ganz einfach - Fehlerbild / Beschreibung und ca. 20 Jahre Erfahrung in PC und Server-Technik.

Ja, zugegeben - Garantie ist das keine, da würde ich aber zumindest mit suchen anfangen...
 

josef-wien

Ultimate Guru
gehrke schrieb:
Inwiefern ein Widerspruch?
Wenn es keine Systempartition gibt, können nicht bloß "jegliche Netzwerkdienste fehlen", dann ist gar nichts vorhanden.

gehrke schrieb:
Bei den FS-Checks vermute ich, dass es Inkonsistenzen infolge des Absturzes gibt.
Die Fehlermeldung ist der 08/15-Text, entscheidend ist die Aussage, daß es die Systempartition gar nicht gibt.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Zwei Dinge habe ich am System geändert, bevor das Problem erstmals auftrat:
*ntp in der bacula-VM aktiviert
*Eine neue Festplatte als Backup-Ziel eingebaut. Diese wird an die VM weitergereicht.
 

marce

Guru
ok, an der Hardware rumgebastelt und hinterher tut nichts mehr? Die Info hätte auch früher kommen können...

Wie ist denn die neue HD reingekommen? HotSwap oder rumgeschraubt? Konfiguration der restlichen HDs über dev, UUID, Label, ...? Was sagt das BIOS zu allen beteiligten HDs? Reihenfolge identisch? Neue HD am gleichen Controller oder IDE / SATA / SCSI gemischt? ...?
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
gehrke schrieb:
Inwiefern ein Widerspruch?
Wenn es keine Systempartition gibt, können nicht bloß "jegliche Netzwerkdienste fehlen", dann ist gar nichts vorhanden.
Das ist dann ein Missverständnis.
Mit "jegliche Netzwerkdienste fehlen" war das erste Symptom gemeint. Demnach habe ich mich lokal an das System gesetzt und die Meldungen aus dem Screenshot gesehen.
 
OP
gehrke

gehrke

Administrator
Teammitglied
marce schrieb:
ok, an der Hardware rumgebastelt und hinterher tut nichts mehr? Die Info hätte auch früher kommen können...
Ich plädiere für mildernde Umstände, Euer Ehren.
Kann schon sein dass ich heute nicht mehr der Schnellste bin - und eine frische HD als neues Backupmedium ist nicht wirklich so etwas ungewöhnliches, dass es augenfällig sein müsste. Das passiert im monatlichen Wechsel.
marce schrieb:
Wie ist denn die neue HD reingekommen? HotSwap oder rumgeschraubt? [...] Neue HD am gleichen Controller oder IDE / SATA / SCSI gemischt? ...?
Neustart. Es gibt einen unabhängigen Controller für die Backup-Festplatten, welcher bislang aber nicht zu solchen Effekten geführt hat. Das ganze läuft schon geraume Zeit, nur gab es für Mai eine neue Festplatte ohne Probleme und für Juni ein weitere neue, beide identischer Typ.
 

josef-wien

Ultimate Guru
Eine zusätzliche Platte sollte keine Auswirkungen auf die RAID-Definitionen haben. Gibt es eine Ausgabe bei:
Code:
mdadm -AsR
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
Eine zusätzliche Platte sollte keine Auswirkungen auf die RAID-Definitionen haben.
Zumal diese Platte nicht Bestandteil irgendeines RAIDs ist.

josef-wien schrieb:
Gibt es eine Ausgabe bei:
Code:
mdadm -AsR
Nein. Keine Ausgabe.

Mal unabhängig von der konkreten Ursache - was wird der Grund für den aktuellen Systemzustand sein?
In meiner laienhaften Vorstellung ist es ein mögliches Szenario, dass es aus irgendeinem Grund im laufenden Betrieb zu einem Absturz kam (ob dabei noch Logs geschrieben wurden, kann ich erst feststellen, wenn das System wieder voll gebootet ist. Beim letzten Mal habe ich leider nichts gefunden).
Es folgt ein automatischer Neustart, der aber scheitert, weil
A: entweder beim Absturz Meta-Informationen für das RAID verloren gegangen sind
B: schlicht niemand da war, der die Passphrase für den LUKS-Container eingegeben hat und es zu einem Timeout kam. In diesem Fall wäre mir aber unklar, warum nicht wenigstens das RAID md1 angezeigt wird.
Dieses Scheitern bringt mich dann auf die busybox.

Ist das plausibel?
TNX
 

josef-wien

Ultimate Guru
Die Informationen über das RAID sind auf allen beteiligten Platten vorhanden. Ich kann mir keinen Systemabsturz vorstellen, bei dem alle diese Informationen in Mitleidenschaft gezogen werden.

Ich interpretiere
gehrke schrieb:
Auf dem RAID md1 liegt ein LUKS-Container und darin eine LVM-Partitionierung.
so, daß zuerst das RAID6 aufgebaut wird und danach Entschlüsselung und LVM-Aufbau erfolgen. Bei dieser Interpretation hätte ich eine Ausgabe des mdadm-Befehls erwartet, das Schweigen deutet üblicherweise an, daß nichts zu tun ist. Durch die Anzahl der Platten und die Zeilenbegrenzung des Bildschirms wird der zusätzliche Parameter -v (dann kommen sehr viele Zeilen) wahrscheinlich auch nicht weiterhelfen.

Nachdem ich den init-Prozeß Deiner initrd nicht kenne (bei openSUSE war er schon vor systemd ziemlich komplex, bei PCLinuxOS (das nash verwendet) besteht er in meiner Variante einschließlich echo-Anweisungen aus 61 Befehlen), habe ich keine Ansatzpunkte.
 
Ich bin so gut wie überhaupt nicht in CentOS drin aber ein paar Dinge: Die Screenshots zeigen einen Rechner der neu gebootet wurde. Der Rechner findet irgendwelche Devices nicht. Der Rechner verfällt dann in eine Notfall-Shell, also nix busybox sondern aus der initrd heraus.
Du hast mindestens zwei Controller verbaut.
Nun kommen die doofen Fragen: Was für eine Serverhardware verwendest Du? Was für Controller sind verbaut? Gibt es im Bios/UEFI den Punkt "Reihenfolge der Controller beim booten"? Werden deine Festplatten in deiner Konfiguration fürs Raid über /dev/sdx angegeben oder über eindeutige Namen? Festplatten hast Du schon per hdparm mit einer Live-DVD gecheckt?
Meine Vermutungen: Die Reihenfolge der Controller beim booten hat sich getauscht, evtl. durch "weich gewordenen" Controller. Damit hauen dann die /dev/sdX Bezeichnungen nicht mehr hin und das Raid (ein Soft-Raid) kann nicht gebaut werden. Evtl ist einfach auch nur eine Platte matschig ala Blinker: geht, geht nicht und bringt damit das Raid durcheinander.
Ansonsten sind Späße wie RAM, Netzteil oder Motherboard tatsächlich auch Kandidaten die solche Fehler verursachen können. Hast Du evtl. in letzter Zeit Updates gemacht? Möglicherweise ein neuer Kernel der Probleme macht?
 
OP
gehrke

gehrke

Administrator
Teammitglied
Danke für die Antworten bislang!

Die allermeisten Fragen kann ich erst beantworten, wenn der Server wieder gestartet ist bzw. ich im BIOS war. Aktueller Stand ist aber noch wie beschrieben (Notfall-Shell) - in der Hoffnung, da noch Informationen herauszukitzeln. Für letzteres gibt es wohl keine Ansätze mehr, daher werde ich mal versuchen, die Büchse am Abend zu booten.

Falls das klappt, werde ich neben der LogFile-Analyse insbesondere mal einen Check der jüngst hinzugekommenen Backup-Disk durchführen.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Hast Du evtl. in letzter Zeit Updates gemacht? Möglicherweise ein neuer Kernel der Probleme macht?
Zumindest das kann ich für den Host ausschliessen. Die VMs werden gepatched, aber das betreffende Host-System darunter wurde seit laaaanger Zeit bewust nicht mehr gewartet.
 

josef-wien

Ultimate Guru
gehrke schrieb:
daher werde ich mal versuchen, die Büchse am Abend zu booten
Das wird nur funktionieren, wenn es sich um eine temporäre Unpäßlichkeit gehandelt hat, und daran glaube ich nicht (aber möglich ist alles).

Eine (auch theoretische) Erklärung für das RAID-Problem fällt mir nicht ein. Hoffentlich gibt
Code:
mdadm -Asv
in einer grafischen Konsole eines Live-Systems (das mdadm an Bord hat) Erhellendes.

Geier0815 schrieb:
Gibt es im Bios/UEFI den Punkt "Reihenfolge der Controller beim booten"? Werden deine Festplatten in deiner Konfiguration fürs Raid über /dev/sdx angegeben oder über eindeutige Namen?
mdadm arbeitet mit seinen eigenen Array UUID und Device UUID:
Code:
mdadm --examine /dev/sd{a,b}1 | grep UUID
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
Durch die Anzahl der Platten und die Zeilenbegrenzung des Bildschirms wird der zusätzliche Parameter -v (dann kommen sehr viele Zeilen) wahrscheinlich auch nicht weiterhelfen.
Hier der Output von
Code:
mdadm -Asv
noch aus der Notfall-Shell:
k7xIdV.jpg

Ein Paging war leider nicht möglich.
 

marce

Guru
Code:
mdadm -Asv | more
geht nicht? Oder eine Umleitung der Ausabe in eine Datei?

... und poste mal die Ausgabe von fdisk -l - ich habe immer noch das Gefühl, daß da eine HD wo reinspukt, wo sie nicht hin sollte...
 
Oben