Ominöse Abstüze FreeBSD Server

M

medV2

Well-Known Member
Hallo,

in meiner Verzweiflung wende ich mich mal an die Community hier :)

Ich habe einen Homeserver auf FreeBSD 11. Das ganze läuft auf einem ca. 5 Jahre alten Dell Rechner mit ECC Ram, der zuvor seinen Dienst problemlos als Workstation unter Linux (Fedora) tat.

Setup wie folgt:

ada0 -> geli mit hmac/sha256 und aes-xts, auf / (ufs)
ada1,2,3 -> geli mit aes-xts ohne hmac, zfs darüber als zpool in /data

Services: ctld, samba, cups, dlna, ssh

Nun zu meinem Problem:

In unregelmäßigen Abständen friert das Teil ein, kein Output auf den ttys, nichts in den Logs, er reagiert einfach auf nichts mehr und muss über den Powerbutton hart resettet werden.

Bei viel IO auf / (der ufs Platte ada0) kann ich das sogar nachstellen (zu ca. 70% friert er z.b. bei einem kompletten svn co der FreeBSD Sources ein). Die Platte ist aber in Ordnung.
Zwischen IO auf dem ZFS Pool und dem Einfrieren konnte ich bis jetzt keinen direkten Zusammenhang herstellen. Allerdings tritt das Problem auch bei anderen Tätigkeiten, oder auch im Leerlauf auf (ohne IO auf der / Platte ca. alle 3-4 Tage).

Die Hardware ist meines erachtens in Ordnung, auch Temperatur habe ich schon überwacht.

Hat von euch jemand Ideen? Bin für alles offen!

LG
 
Hi,

Einfrieren hatte ich auch bei der Nutzung von ctld. Vielleicht liegt es daran. Gibt es eine Kernel-Panic und wenn ja, wie sieht die aus? Steht irgendwas in den Log-Files? Memory-Check gemacht? Wieviel RAM hat der Rechner?

Viele Grüße

Morfio
 
Hallo,

keine Kernel Panic und wie schon beschrieben nichts in den Logs. Rechner hat 4GB ECC und Memorycheck war ohne Befund. Denke nicht das es am ctld liegt, da, wie geschrieben, es auch ohne jegliche Last (nichtmal ein iscsi Vol vom ctld gemounted) zu diesem Einfrieren kommt.

LG
 
Hoi medV2Bär,

bei Dell Maschinen gabs das schon häufiger. In der Regel war da ein Bios im Spiel wo nicht ganz ok war. Hast Du mal schaut ob das up-to-date ist ?
Bei allen anderen Fällen war es bisher immer der Arbeitsspeicher der meichelig war und oft leider im Test auch unauffällig.

Gruß Bummibär
 
mhmm, das BIOS ist in der Tat nicht das akutuellste. Werde ich sobald wie möglich updaten. Derweil bin ich dennoch für weitere Vorschläge offen.

LG
 
Hallo und willkommen :)

Bei solchen komischen Sachen, wäre ein Hardware Check sicher überlegenswert. Folgendes würde ich mal prüfen:
  • Die Hardware reinigen (Staub entfernen, Lüfter prüfen etc.)
  • Die SATA Kabel prüfen oder ersetzen
  • RAM prüfen mit Memtest (Auf vielen Linux-LiveCD's vorhanden)
  • Festplatten prüfen (defekte Sektoren, SMART Werte auslesen)
  • Komponenten austauschen zum prüfen (HDD oder nur 1 RAM Riegel einbauen)
  • Firmware Updates!
Auf ada0 verwendest du UFS warum? Ich fahre seit Jahren sehr gut mit "ZFS only".

Gruss
 
Hallo,

der PC wurde vor wenigen Monaten gereinigt, da sollte alles passen. Auch sind die Dell ja meist so gebaut, dass kein Staub ansetzt.

Platten + SATA Kabel sind geprüft und passen.

Memcheck zeigt nix (10+ Durchläufe).

SMART sagt alles passt. Auch Selftests schon gemacht.

RAM habe ich schon geprüft (auch auf verschiedenen Slots). HD schließe ich aus, da es auch in 100% Leerlauf passiert.

BIOS werde ich heute aktualisieren, der Rest ist aktuell.


Ich fahr seit Jahren (seit 8.0) gut mit UFS. Da ich auf ada0 keine zfs-features brauche bin ich dabei geblieben.

LG
 
Hi,

welche Festplatten hast du verbaut? Ich hatte mal Samsungs verbaut, die laufend zum Stillstand des Systems geführt haben, egal ob mit oder ohne Last. Dennoch würde ich auch ctld nicht unbedingt ausschließen und mal probieren, ob ohne ihn auch die Freezes auftreten.

Viele Grüße

Morfio
 
Wenn du sagst, dass die Maschine "einfriert", meinst du dann, dass sie einfach stehen bleibt und keinen Mucks mehr von sich gibt, oder sind durchaus noch Eingaben möglich, Kommandos werden lediglich nicht zu ende ausgeführt und lassen sich auch nicht strg-c abbrechen?
 
Empfehlung einer Livedistro zum Testen der Hardware:
http://distrowatch.com/table.php?distribution=stresslinux

Laufen die Dienste in seperaten Jails? Wenn der Host einfriert könnte man dann wenigstens die Dienste der Jails ausschließen... Irgendwelche Sonderdinger auf dem Server, wie X11 über ssh?

medV2 schrieb:
In unregelmäßigen Abständen friert das Teil ein, kein Output auf den ttys, nichts in den Logs, er reagiert einfach auf nichts mehr und muss über den Powerbutton hart resettet werden.
Zum Vergrößern anklicken....
Damit sind vermutlich auch simple Pings zum Gerät gemeint?
 
Zuletzt bearbeitet:
Hallo,

ad morfio: Ich habe in der tat eine Samsung (im ZFS Pool). Eine Samsung, 2 WD und 1 Seagate. Ich werde mal versuchen das ganze ohne ctld nachzustellen. Aber ich hatte bisher noch nie Probleme damit (setzte den auch beruflich gerne ein).

ad yamagi: Nein, nichts ist mehr möglich, nur noch lang auf den Powerbutton hilft. Selbst am Switch sehe ich keine Packete.

ad mogbo: CPU / Network Stresstests habe ich schon erfolglos versucht, aber ich werde das probieren sobald ich Zeit finde. X11 läuft nicht, auch sonst nichts "ungewöhnliches". Jails laufen keine. Ping und co geht natürlich auch nicht.

LG
 
medV2 schrieb:
Nein, nichts ist mehr möglich, nur noch lang auf den Powerbutton hilft. Selbst am Switch sehe ich keine Packete.
Zum Vergrößern anklicken....
Dann ist es sehr wahrscheinlich kein Deadlock, denn dann wäre das System noch teilweise ansprechbar. Wenn es dir den Aufwand wert ist, wäre der nächste Schritt einen Kernel mit Debugger zu bauen, wenn das System hängt diesen aufzurufen und herauszufinden, wo genau er stehen geblieben ist: https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html
 
KobRheTilla schrieb:
Wie kommst du darauf, dass eine Verkomplizierung zu besserem Debuggen führt?
Zum Vergrößern anklicken....
Wenn ich das Hostsystem möglichst nahe an der Grundinstallation lasse und alles in seperate Jails setze, führt das finde ich zu einer eindeutigeren Prozesstrennung und ein fehlerhafter Prozess aus dem Userland kann so nicht das System einfrieren.

Vorraussetzung, Fehler kommt nicht von der Hardware und FreeBSD11 ist stabil, von was ich momentan ausgehe.

Ist meine Denkweise, bin damit bisher nicht gegen die Wand gelaufen.
 
Hi,
erstmal danke für eure zahlreichen Ideen.

Das BIOS Update hat erstmal nicht geholfen. Ob es was bringt, die Prozesse in Jails zu setzten bezweifle ich auch, wäre es ein Userland Prozess der spinnt, würde das System nicht derart einfrieren, und es müsste sich was in den Logs sehen lassen, oder zumindest ne Kernelpanic. Werde aber erstmal ctld aus lassen (mit dem haben wohl einige schon schlechte Erfahrungen gemacht) und weitertesten. Andere Versionen von Samba habe ich übrigends auch schon mal probiert, ebenfalls ohne Erfolg (3.X und 4.X).

Ad Yamagi: Ich habe jetzt den Kernel mit dem Debugger gebaut. Mit Strg+Alt+ESC komme ich auch rein, das funktioniert ganz gut. Soll ich also darauf warten, dass wieder alles einfriert, und hoffen das ich über die Tastatur noch in den Debugger komme?

LG
 
Jepp. Zumindest mit einem guten, alten PS/2-Keyboard sollte der Debugger immer triggern. Egal wie schlimm es ist. Tut er das nicht mehr, ist was verdammt böse im Eimer und es stellt sich wieder die Frage nach der Hardware. Bei USB-Keyboards ist es etwas anders, da an USB jede Menge Magie hängt, die gerne zusammen mit dem System krepiert. Egal ob echtes USB oder per PS/2-Emulation durch die Firmware.
 
So, kleines Statusupdate hierzu: Durch den Tipp mit dem Debugger und etwas rumspielen (in erster Linie konnte ich durch den Debugger ordentliche Crashdumps schreiben) kam ich darauf, dass meine ufs-writes bei den Crashes involviert waren. Habe daraufhin meine / - Partition gelöscht, neu erstellt (inkl. geli und newfs). Seitdem, auch unter Last, keine Probleme. Auch bei high writes auf / (ufs) nichts.. Denke also das wars. Dazu sei gesagt, dass meine / noch von 9.0 (oder 9 Beta) stammte, vielleicht lief da irgendwann etwas schief bei den updates..
 
Oder das Dateisystem war einfach kaputt. Gerade, wenn Journaled Softupdates eingeschaltet sind, kann es bei lügender Hardware (also eigentlich aller Hardware im Consumerbereich) dazu kommen, dass fsck das Dateisystem für sauber hält, obwohl es das nicht ist. Oft hilft da auch ein vollständiges fsck zu erzwingen und 2 oder 3 Mal rüberlaufen zu lassen. Bis er keine Fehler mehr findet.
 
Yamagi schrieb:
Oder das Dateisystem war einfach kaputt. Gerade, wenn Journaled Softupdates eingeschaltet sind, kann es bei lügender Hardware (also eigentlich aller Hardware im Consumerbereich) dazu kommen, dass fsck das Dateisystem für sauber hält, obwohl es das nicht ist. Oft hilft da auch ein vollständiges fsck zu erzwingen und 2 oder 3 Mal rüberlaufen zu lassen. Bis er keine Fehler mehr findet.
Zum Vergrößern anklicken....

Also das hab ich viel zu häufig gemacht :D ( vom live Stick ). Immer min. 2 mal, großteils 3 mal...

ach edit: Die HW im Business Bereich ist nicht viel besser. Vor allem die Festplatten...
 
Ist sie wirklich nicht. Ich bin in der Firma auch davon abgekommen den gigantischen Aufpreis für explizite Enterprise-Platten zu bezahlen und beschränke mich auf billige Consumer-NAS-Platten. Läuft auch nicht schlechter. Aber die Controller, sofern man denn in einen SAS-HBA investiert und nicht die Onboard-AHCI-Ports nimmt, sind in Sachen Cachemanagement schon eine Stufe besser. Dafür haben sie dann meist bei so "neuen" Dingen wie TRIM / UNMAP interessante Bugs. Zumindest LSI / Avagi / Broadcom / 'aktueller Name hier' hat da auch nach etlichen Firmware-Revisionen immer noch Zicken.
 
Bin auch ein Fan der WD Red Platten.... Mit gutem Controller genau so schnell wie die SAS. Und dank FreeBSD gibt es RaidZ2/3. Mit LSI und Adaptec Controllern hab ich sehr gute erfahrungen gemacht. Aber "neue" Dinge habe ich bins jetzt immer gemieden im produktiven Umfeld.


// Edit: Wohl gemerkt bevor hier jemand kommt: Das gilt natürlich nicht für high performance fc-san Sachen..
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben