unerklärliche Abstürze

A

athome

Active Member
Hallo Zusammen,

nach einiger Zeit mal wieder eine Frage für die HArtgesottenen unter euch.

Ich habe hier eine BSD 6.1 RELEASE Kiste stehen auf der eine Qmail Server mit diversem Zubehör läuft.

Nun ist aus irgendeinem Grund das /tmp Verzeichnis vollgelaufen und daraufhin der Server abgestürzt. So weit so gut.

Tmp Verzeichnis wieder geleert und alles war gut.

Seitedem macht der Server aber nun alle 1 oder 2 Tage einfach einen Reboot.
Meistens geht alles gut und das fsck im Bootvorgang geht gut, aber hin und wieder
bleibt die Kiste hängen und ich muss manuell einen FSCK ausführen.

Das Problem ist aber, das ich nicht dahinterkomme, was denn den Reboot auslöst.

unter /var/log/messages ist nichts zu finden geschweige denn, das ich irgendwo einen Dump finde oder sonstwas.

Was ich bis jetzt getan habe:

- Kernellimits für TCP Verbindungen eröht
- regelmässig auf genügend Platz geprüft
- von Hand rebootet (er rebootet aber trotzdem)

Gibt es denn irgendeine Möglichkeit noch irgendetwas mitzubebuggen was da alles läuft ?

blöde wirklich wenn man ohne jegliche Fehlerhinweise nach einem Fehler sucht. ich vermute das liegt irgendwie an dem Filesystem aber wenn.... dann WAS ?

ok, in gemountetem Zustand kommt noch die meldung, das der Superblock auf /tmp defekt sei. wenn ich das ganze aber unmounte und dann schaue ist es ok.

genauso wie, wenn ich im single User Mode schaue.

Any Ideas ?
 
athome schrieb:
ok, in gemountetem Zustand kommt noch die meldung, das der Superblock auf /tmp defekt sei. wenn ich das ganze aber unmounte und dann schaue ist es ok.
Zum Vergrößern anklicken....

ist es denn ein eigenes filesystem? vielleicht hilft dann ein "newfs", den korrekten superblock wieder herzustellen.
 
ich hatte das problem mit meinem laptop frueher auch immer gehabt.
bis ich festgestellt hatte dass es ein ganz einfaches hitzeproblem gewesen ist!

einfach mal den cpu-luefter durchgepustet und alles funzte wieder tip-top.
 
Hallo zusammen !

Danke erstmal für die Vorschläge :-)

@ Elwood --> hätte ich auch selbst draufkommen können, danke ! Ich denke das sollte recht zielführend sein. Zieht das denn auch, wenn der Rechner mitten im Betrieb.. plötzlich einfach Rebootet ? schafft es der Kernel dann noch einen Dump zu machen ? Ich bin misstrauisch. Irgendwas knallt... aber ich kann nicht sagen was... werde es aber versuchen !

@ makenoob --> habe ich noch nicht probiert, das wäre die m.E. letzte Konsequenz. Allerdings würde ich dann eher bevorzugen, das komplette System neu aufzusetzen, vorher einen Dump ziehen und neu drauf.. aber das kostet ZEIT... da es sich um einen betriebsserver handelt... nee nur ungern.

@ dettus Naja.... kann ich mir so nicht vorstellen. 1. der server steht in einem RZ mit Vollklimatisierung, alle der 12 Lüfter laufen (Dell Server) und ich habe festgestellt, das ich das Problem auch auf einem anderen Rechner habe. ICh muss echt noch suchen ! *grummel*
 
für mich klang es so, als wenn du /tmp auf einer separaten partition oder platte hast und er sich deswegen beschwert. dann könnte man ja kurz in den singleuser mode und newfs drüberlaufen lassen.
 
athome schrieb:
@ Elwood --> hätte ich auch selbst draufkommen können, danke ! Ich denke das sollte recht zielführend sein. Zieht das denn auch, wenn der Rechner mitten im Betrieb.. plötzlich einfach Rebootet ? schafft es der Kernel dann noch einen Dump zu machen ? Ich bin misstrauisch. Irgendwas knallt... aber ich kann nicht sagen was... werde es aber versuchen !
Zum Vergrößern anklicken....

Hi,

nein, wenn der wirklich wegsemmelt (-> Reset) dann wird da nichts draus. Aber das System erkennt beim Hochfahren, ob auf der Swap-Partition ein Speicherdump liegt. Du musst mal im /var/log/messages gucken bzw. beim Hochfahren darauf achten.

Solche spontan-Resets können auch durch defekten Speicher kommen. Ggf. solltest du mal Ersatzriegel zum Testen reinpacken.

Gruss, Elwood
 
@ Elwood sowas habe ich schon befürchtet. Der Speicher kanns eigentlich nicht sein, habe ich schon mehrfach getestet. zudem ist das selbe Problem in der selbe Ausprägung auch auf einem anderen Server, allerdings erst nachdem eine partition vollgelaufen war. Ich vermute irgendwas mit dem Filesystem... sonst gibts ja eigentlich kaum was, was den Server ausm Tritt bringt. Ist ne minimalinstallation mit qmail und Zubehör drauf... das läuft auch alles wunderbar. nur eben diese SCh*** Abstürze oder resets... und zwar echt hart. Ich weiss nur nicht ob.. die resets wegen dem FS kommen oder ein Resultat der Resets sind. Irgendeine Idee wie ich das rausfinden kann ??? Werde esmal in der Tat mit einem Debuggig Kerne versuchen... vllt. seh ich ja was.

@makenoob Naja... das hab ich ja schon gemacht. wie geschrieben zeigt fsck dann keinen Fehler mehr an. also.. muss oder kann es ja nur was anderes sein. *überlegt*
 
mir ist mal nen cpu-lüfter abgeraucht und deshalb hat sich die kiste immer mal resetted. irgendwann war die cpu dann so heiss, dass er auch beim prüfen sich resetted hat, und da hat dann selbst nss (netware) nicht mehr mitgespielt und die kiste war hin und brauchte nen neues system (und nen neuen lüfter).

EDIT: es ist ein dual-p3 system, und die der lüfter der zweiten cpu war hin...
 
Deaktivier mal ACPI falls du es nicht brauchst (was ich am Server für wahrscheinlich halte).

Neben dem hier diskutierten Fall hatte ich nun auch noch einen anderen, bei dem wie in deinem Fall KEINE Meldung ausgeworfen wurde. Dieser Server läuft nun ohne ACPI ebenfalls seit Wochen ohne Absturz.

Viel Glück!
 
Ich hatte mal ein ähnliches Problem. Mein Rechner ist auch ständig abgestürzt, hat allerdings keine Meldungen hinterlassen. An einem vollen Dateisystem lag es allerdings nicht.
Wie sich später dann rausstellte war das Netzteil hinüber; unter Last hat das dann nicht mehr mitspielen wollen und ist ausgestiegen.

Vielleicht hilft's Dir ja weiter. ;)
 
leider bin ich hiermit noch nicht weitergekommen....

deswegen auch der andere thread.. ich versuch die beiden Server mal HA zu machen...
das wenn einer wegfällt.,.. der andere übernimmt ;)

das Problem hier löse ich auch noch....
 
Ähm... wie meinst du das, wo gibts das ?

Naja mittlerweile ist es FreeBSD 6.2-RELEASE

oder was meinst du .. current / stable ?!?!
 
Vielleicht Festplatte?

Man sollte nicht vergessen das Festplatten sich auch heute noch verbrauchen, hatte mal ein ganz Ähnliches Problem, allerdings mit einem Billiggehäuse, da waren so Schnellspanner für die Festplatten drin, die nicht-leitend waren, habe dann einfach einen Kupferdraht von dem Festplattengehäuse an das Gehäuse des Netzteils geführt und angetaped, dann ist es gegangen - frag mich nicht warum, aber ich hatte festgestellt, dass immer nachdem ich nachgeschaut habe ob nicht irgendeine Verbindung wackelig ist, das ganze wieder für eine Stunde etwa ging, also dachte ich an Erdung. Das zweite Mal als ich ein ähnliches Problem hatte, war es nicht mehr so zu lösen, das war ein anderer Rechner und der hat dann auch mit Windows (war auf der gleichen Platte wie OpenBSD 3.9) Bluescreens gemacht - am Ende hat nur eine neue Festplatte geholfen.
 
Hmmm..... soweit hab ich das alles schon erlebt.

aber.. hier Dell Server PowerEdge

--> Disks Redundant als RAID 1 angelegt
--> mit allem möglichen Überwacht
--> selbst wenn eine Ausfällt geht das ja noch weiter....

und vorallem... der Controller merkt ja wenn was ausfällt

zudem spricht dagegen, das das Phänomen auf 2 Server auftritt !
 
ok, in gemountetem Zustand kommt noch die meldung, das der Superblock auf /tmp defekt sei. wenn ich das ganze aber unmounte und dann schaue ist es ok.
Zum Vergrößern anklicken....
- hm, das tmp-filesystem einfach neu zu machen, nur so, zum versuchen, dürfte auch nicht viel mehr Zeit kosten. Gibt es denn irgendwelche Anhaltspunkte was bei den beiden Servern das einmal vollgeschrieben hat - scheint ja irgendeine Rolle zu spielen, zumal die Resets erst dannach angefangen haben? Hast du die Kernel irgendwie modifiziert? Hast du mal Ne0ns Vorschlag probiert, das acpi auszuschalten? - ist natürlich blöd wegen der Stromrechnung, aber zwecks Fehlersuche meine ich, was für einen RAID-Controller verwendest du? - manchmal hilft da ein BIOS-Update (war z.B. bei meinem ASRock 939 Dual SATA 2 - Motherboard so, weil das RAID quasi nur eine Funktion des Plattencontrollers ist, die das BIOS übernimmt; OpenBSD nennt das "cheap sofware-RAID", das sie nicht unterstützen, bei einem "echten" Hardware-Raid geht das natürlich nicht, aber vielleicht ein Firmware-Update, falls das noch anders als durch Jumper verstellbar ist), das Vollschreiben von tmp könnte jedenfalls ein RAID-Fehler gewesen sein. Was heißt "mit allem möglichen überwacht"? - Vielleicht ist einer der Wächter etwas zu paranoid und schaltet ab, obwohl das gar nicht nötig wäre?
Mehr fällt mir nicht ein.
 
Hallo Kong,

also erstmal vielen Dank für die Anregungen.

Ich werde da nach der Reihe darauf eingehen.

- tmp neu anlegen ist m.E: das was ich noch versuchen kann.
- es gibt leider keine Anhaltspunkte. die TMP war voll, anschließend hats den Server runtergerissen, dann wurde wieder TMP 1 % belegt. ok.
- Stromrechnung spielt keine Rolle, da die beiden Server im Rechnezentrum stehen.
sind schliesslich Produktionsrechner
- ACPI hab ich ausgemacht, aebr das selbe Phänomen ! MIST
- Blos kein Software RAID wozu haben wir schliesslich diese netten Dell Serverchen.
- Der Raid Controller ist ein PERC 4/DI Controller mit aktuellster Firmware
- systeminterne Sensoren überwachen alle HArdwarekompontenten und geben das dann aus (RAC Controller) Plattenfehler definitiv keiner.

Ich vermute einfach, das nach dem Vollaufen und dem Abstürzen des Servers danach irgendwas an der Partition beschädigt worden ist, was so nicht auf den ersten Blick sichtbwar wird.,

Ebenso hab ich bemerkt das seit einiger Zeit auch Qmail anfängt mit einem "Signal 11 " auszusteigen.

Denke das wird darauf rauslaufen, das ich die Kiste neu aufsetze. Vorher ein backup der Konfig und dann schau mer mal....

Ich hoff nur das ich die 250 User nicht nochmal neu einrichten muss .... argh... na.. schau mer mal
 
es wird immer besser

nun hat der eine der beiden Server angefangen alle 2 Minuten neu zu booten.

folgendes habe ich gemacht um endlich mal einen Crashdeug hinzubnekommen

etc/rc.conf

dumpdev="AUTO" reingeschrieben

das blöde ist aber, das der Server wohl diese Meldung nicht interpretieren kann.
also.... in der /var/log/messages steht das er den pfad nicht finden kann.

laut Anleitung muss ja eine SWAP Partition mit ausreichender Grösse da sein, das ist der Fall !

- USB HAb ich im BIOS des Servers ausgeschaltet
- COM Hab ich im BIOS des Servers ausgeschaltet
- eine der beiden Ethernet Adapter hab ich ausgeschaltet

... was mich nur stutzig macht ist, das sich die Problematik wohl verstärkt
das deutet doch eigentlich darauf hin, das sich was verändert.

alle tests (anderer speicher, andere CPU, etc ) haben aber das selbe Resultat. NIX
 
sorry aber....das glaube ich weniger.

nochmal ein SERVER DELL PowerEdge 1750

Redundante Netzteile voll überwacht, restriktiv eingestellte überwachung, bei Spannungsschwankung erfolgt ein Failover auf das andere Netzteil. Umschaltzeit < 50 ms

irgendwie bin ich zu blöde für alles.... verstehe nicht warum er die Option
dumpdev="AUTO" nicht haben will.

möcht doch nur nen Kernel Dump haben wenn er abschmiert ;)

danke aber trotzdem
 
athome schrieb:
sorry aber....das glaube ich weniger.

nochmal ein SERVER DELL PowerEdge 1750

Redundante Netzteile voll überwacht, restriktiv eingestellte überwachung, bei Spannungsschwankung erfolgt ein Failover auf das andere Netzteil. Umschaltzeit < 50 ms

irgendwie bin ich zu blöde für alles.... verstehe nicht warum er die Option
dumpdev="AUTO" nicht haben will.

möcht doch nur nen Kernel Dump haben wenn er abschmiert ;)

danke aber trotzdem
Zum Vergrößern anklicken....

Wenn es die Dell Diagnostics für deinen Server gibt solltest Du die mal komplett durchlaufen lassen.
 
Gelöst !!!

Hallo zusammen,

ich wollte nur noch schnell hier hinterlassen, das das Problem mit den Abstürzen endlich gelöst ist. Nachdem ich einige Zeit nicht dazugekommen bin, nach dem problem zu schauen habe ich wieder angefangen zu debuggen.

Schau an, was kam dabei heraus:

der TSCPERVER war es, der sich mit ein paar Bibliotheken gebissen hat.
ich konnte das anfänglich nicht umgehen, da ich keine neueren Bibliotheken gefunden habe.

Dann kam mir die Idee das komplette BS auf 6.2 Upzudaten. Ja, das war es. Die Bibliotheken sind neu und die Abstürze vergessen.

Blöde nur, das im Grundegenommen nicht das Filesystem daran schuld war, sondern nur so ein blöder TCPSERVER

Ihr könnt Informationen darüber finden wenn ihr googelt: "tcpserver Pagefault fatal trap 12"

Trotzallem möchte ich mich bei allen recht herzlich bedanken, die mir bei der Lösung des Problems mit Rat und Tat zur Seite standen !

Grüsse

Athome
 
also wenn du jetzt den fehler zwar gefunden hast, .. solche probleme konnt ich meist nur mit ausgetauschter hardware loesen.

hatte mal nen 5.4 fbsd release auf nen pIII dual 800Mhz system aufgesetzt, das urploetzlich alle 30min abgestuertzt und rebootet hatte. dummerweise muss das freitags nachmittags begonnen haben, und uebers weekend hats niemand bemerkt....

das uebl an der sache war das mainboard, saemtliche kondensatoren auf dem brett waren unendlich hohe widerstaende geworden =) ... aber das gute war, selbst nach den unzaehligen abstuertzen was das fs noch absolut okay. neues mb eingebaut, und schon lief die kiste wieder ihre 24/7 =)

mfg
 
Zuletzt bearbeitet:
Hallo,

hier mein Erfahrungsbericht zu spontanen Systemabstürzen.

Ich beziehe mich auf mein System (derweil 16 Monate jung mit FreeBSD 6.1 bestückt und gehoused bei einem professionellem Rechenzentrum ) und dem themenverwandten Fred.

Das System lief stabil bis zu einer Uptime von ~90 Tagen (vorher musste das System wegen neuen Kernel-Patches routinemäßig ohne Zwischenfall neu gestartet werden). Auf einmal kamen spontane Reboots ohne irgendwelche Hinweise in den Logs dazu (Dumpdevice habe ich bis heute nicht aufgesetzt). Die üblichen Verdächtigen wurden untersucht beginnend bei der Hardware gemäß der Checkliste in eurem Wiki. Es zeigten sich keine Auffälligkeiten, die neue und gute Server-Hardware als auch die Housingumgebung ließen auch keinen Grund zur Beanstandung zu.

Dann wurden die Softwarestände/Patches (Kernel, Userland, Ports) geprüft bzw. aktualisiert und soweit war alles akkurat bis auf PHP5, dessen nicht mehr ganz aktuelle Version Sicherheitslücken aufwies. Entsprechend wurde dann auch der Port aktualisiert.

Gut, das half auch nichts. Das System stürzte irgendwann wieder ab.

Nun ging es an das Tuning der Konfiguration von Kernel und Ports, ACPI wurde abgeknipst und die in Verbindung stehenden Performance-Parameter (php, mysql, Kernel-Paramter) wurden moderat eingestellt.

Auch das half nichts und der Absturz trat bald täglich auf.

Ab dem Punkt zeichnete sich eine Muster ab und mir ging allmächlich ein Licht auf. Was lief noch auf dem System? Backup-Jobs so wie sich das gehört. Einmal tägliche inkrementelle Dumps über die Filesyteme, die absolut stabil mit Snapshots laufen und noch nie ein Problem bereiteten. Dann liefen noch tar-Jobs über die einzelnen WebSpaces der Kunden, indem immer die letzten 3 geänderten Tar-Archive zurückgehalten wurden und sich schnell Daten der Kunden rekonstruieren lassen. (Japp, dafür nimmt man rsync beim Provider, etc. Ich aber nicht. Die Kosten für den rsync-Dienst habe ich in eine USB-Platte als redundantes Backupmedium gesteckt - jene läuft einwandfrei und war auch nicht als Sündenbock der Abstürze zu bezichtigen - und die Daten bleiben aus der Reichweite Dritter. )

Tja, und der Absturzzeitpunkt deckte sich dann in der Tat mit einem Tar-Cronjob über ein Unterverzeichnis (tar-Archiv unkomprimiert 500MB klein) wo sich die Dateien aber ansonsten kaum ändern. Und mit dem Script ließ sich der Absturz punktgenau beliebig oft reproduzieren! Nach dem Reboot wurde gleich das Filesystem geprüft, es zeigte keine Fehler auf, doch das Script ließ die Maschine wieder abstürzen. Die Daten wurden auf einem neuen Filesystem angelegt aber auch das brachte keine Abhilfe und wurde wieder mit einem Systemabsturz quittiert.

Das Backupscript macht nicht viel und erzeugt mit bsdtar komprimierte bz2s über das Filesystem. Vielleicht gab es mit der Komprimierung des Archivs ein Problem. '-j' abgeknipst für unkomprimierte Tarballs beseitigte das Problem jedoch nicht.

Zweifelsohne hatte es also mit dem nativen bsdtar (wurde natürlich auch aktualisiert) zu tun. Das wurde sogleich gegen star ausgetauscht und mit suntar-Header betrieben. Ab dem Punkt läuft alles wieder problemlos ohne jeden Zwischenfall und das System liegt derweil bei einer Uptime von 50 Tagen!

Was jetzt genau der Haken in Verbindung mit genau dem Filesystem und bsdtar steht (denn nur in dem Fall trat ja das Problem auf) weiß ich nicht und werde wohl erst dann schlauer, wenn die Daten auf ein anderes System mit FreeBSD 7.1 und zfs Storage migriert wurden. (Um das nochmal ganz klar zu sagen, die Migration ist nicht notwendig und das aktuelle System ist nach wie vor Produktion und läuft extrem sauber. 7.1 und die zukünftige Erfahrung und Vorzüge mit zfs will ich aber nicht missen. ). Nebenbei bemerkt gefällt mir die doofe tar-Backup-Lösung nicht mehr und ich werde vielleicht doch noch auf richtige inkrementelle Backups von Unterverzeichnissen ausweichen mit einem lokalen rsync, was auch immer.

Soweit meine Erfahrung zu spontanen Systemabstürzen.

--

Und jetzt noch was zum Thema NICHT spontane Systemabstürze und DoS. Anfangs hatte ich da ganz schlechte Erfahrung mit "ftpd-tls-20031008_2" gemacht. Eine DoS Attacke ließ das System zwar nicht abstürzen verweigerte dann aber alle Netzwerkdienste mit dann notwendiger manueller Intervention direkt vorm Server Rack.

Den Dienst hatte ich dann sogleich mit "bsdftpd-ssl" ersetzt und ausschließlich Authentifikation mit Zertifikaten (und "hosts.allow" Einschränkung) eingeführt. Seit dem läuft der Dienst sehr zufriedenstellend. Was das Problem bei der anderen Software ist - von 2003(!?) bzw. nicht konfigurierter restriktiver Authentifikation - weiß ich nicht. Ich frage mich aber dennoch, warum so ein Paket noch in den Ports [durchstreich]gepflegt[/durchstreich] enthalten ist obwohl es ja scheinbar aktuelle, stabile, mit mehr Funktionsumfang, auch wenn mehr Resourcen gefordert werden, Alternativports gibt.

Okay, das war es aber jetzt. Danke an das Team für euer Forum, euer Wiki die vielen Tipps und and die User hier für weitere Hinweise, Diskussionen und spannende Fehlerdiagnosen.

In der BSD Welt kann man definitv nicht sagen, man wäre ganz alleine auf sich gestellt.*thumbs up* ;-)
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben