Server-Sekunden-Tod, klinisch keine Anzeichen dafür ....

[Anonymous]

Ich bin mit meinem Latein am Ende .....

In den Log Dateien ist nichts, aber auch gar nichts zu finden das die Kiste auf irgendwas panisch reagiert und sich deshalb weghängt.

SuSE 9.1
Kernel 2.6.9, also schon fast der aktuellste
MySQL 4.0.18
Apache 2.0.49 mit PHP 4.3.10

Ich finde weder Fehler in /var/log/messages noch /var/log/warn noch /var/log/boot.msg oder in sonst einer Datei.
Keine MySQL Fehler, keine Apache Fehler keine sonstigen Fehler.

Ich bin gezwungen per Reset den Server neu starten zu lassen, wobei dann jedes mal einige Tabellen in den Datenbanken defekt sind und zum Teil ersetzt werden müssen.

Einzig was nicht wirklich richtig funktioniert ist die Serielle Konsole. Nur ich denke das es mit dieser Problematik nichts zu tun haben könnte.


Ich hab nun schon ca. 3 Jahre mit LinuxServern meine Erfahrungen gesammelt, aber diese Kiste treibt mich zur Verzweiflung.


Wie finde ich den Fehler?
Einfach neuen Kernel backen und drauflos wuseln dürfte wohl ganz sicher nicht _die_ Lösung sein. Zumal ich mit neuem Kernel bauen noch nie Glück gehabt habe. (Kann sich ja mal ändern ;o))

Ich weiß mir echt keinen Rat mehr. .......
Kann mir jemand dabei helfen?


Mirko

[niemand]

Wenn in den Logfiles wirklich kein Hinweis zu finden ist, könnte vielleicht ein kleines Script, welches die Parameter überwacht und in eine Datei schreibt, einen Hinweis liefern. Zunächst würde ich aber erstmal die jeweils neuesten Versionen installieren.

cu

[Anonymous]

Script ... ok ...

Nur welche Parameter?!

Aktuell gibt's nen Monitoring in Sachen CPU, Speicher, Netzwerklast

Da ist nix zu finden was auf ungewöhnliche Aktivitäten hinweist.

[Anonymous]

PS:

Das war das letzte was mir die Serielle Konsole anzeigte, bevor ich einen Reset durchgeführt habe:

Code: Select all

Linux version 2.4.27-040930 (jacko@neverland) (gcc version 2.95.4 20011002 (Debi
an prerelease)) #1 SMP Thu Sep 30 19:03:28 CEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
 BIOS-e820: 000000000009ac00 -

Und das war es dann auch.
Hängt es doch damit zusammen?! Denn nach dem Reset sind da keine weiteren Azeigen mehr gekommen ....

[Joe User]

http://www.google.com/search?hl=en&q=%2 ... gle+Search
http://www.google.com/search?hl=en&q=%2 ... gle+Search

[Anonymous]

Ã?hem .. Joe ... mag sein das Du damit etwas anfangen kannst.
Nur gehe ich der Vermutung mal nach, das da Tausende ihr Logfile irgendwo gepostet haben. Denn nix anderes sehe ich bei deinen Links da.

Bei meinem Problem hilft das nicht wirklich weiter.

[spiderman]

hm, sicher, das es sich dabei nicht vielleicht um einen Hardwaredefkt handelt?

irgendein lüfter oder so?

[Anonymous]

An die Hardware komm ich leider nicht ran. Von daher kann ich keinerlei Aussagen treffen. Gemietet bei S&P ;o)

[metrax]

Einfachste Lösung: S&P connectieren, Problem schildern, Hardware checken lassen ;)

[Anonymous]

Einfachste Lösung: S&P connectieren, Problem schildern, Hardware checken lassen ;)

Schon passiert. Angeblich ist da nix zu finden.
Aus dem Grund such ich ja nach ner anderen Lösung, um des Problems Herr zu werden.

[Anonymous]

Leuts ... drückt mir mal bitte die Daumen, ich glaube ich habe den Fehler letzte Nacht gefunden und behoben.

Es lag vermutlich am Kernel. Vermutlich deshalb da er erst mal ohne Probleme läuft.
Installiert war ein kernel 2.6.9 mit MPENTIUMIII ... (3)

Ich hab gestern den aktuellen Kernel 2.6.10 mit MPENTIUMIIII ... (4) kompiliert und installiert. Und "juchuuuu" .. ;o)
Es war der erste Kernel den ich jemals zum laufen bekommen habe. Von daher wars schon mal nen Erfolg ;o)

Falls jemanden interessiert warum gerade diese Idee.
Mir ist mit dem MySQL aufgefallen, das der versteckt am laufenden Bande Probleme mit Speicherzugriffen hatte. Und gestern mal ne Meldung mit der ich etwas anfangen konnte:
"Korrupte Dateien" ... bzw. das der Absturz mit; "malfunctioning Hardware" im Zusammenhang liegen könnte.

Komplette 2.6.10 Source von Kernel.org geholt und make oldconfig fragte nach der CPU .. die auf Pentium III (Celeron/Xenon etc) voreingestellt war. Und meines Wissens nach ist's ne P4 CPU.

Also wenn es tatsächlich genau dieses Problem gewesen sein sollte (ich hoffe es), dann kann sich Provider warm anziehen ....

Mirko

[sir tom]

Und meines Wissens nach ist's ne P4 CPU.

Das sollte man aber doch schon genau wissen?

cat proc "cpuinfo"

[chris76]

cat proc "cpuinfo"

cat /proc/cpuinfo

[Anonymous]

*lach*

Genau in der Datei hab ich ja nachgesehen ;o)
Und da stand etwas von Version 4 ;o) Jedoch traue ich dem Braten nicht immer sofort. Computer können so gemein sein ... *heul*

Seltsamer Nebeneffekt:
Der MySQL nimmt sich jetzt "endlich" etwas mehr Hauptspeicher. Vorher war bei 42 MB Schicht. zur Zeit nutzt er 92MB, was nen wesentlich vernünftigerer Wert ist.

[captaincrunch]

Und trotzdem glaube ich kaum, dass dieses Setting für dieses Verhalten verantwortlich ist. Eher war der alte Kernel ziemlich bescheiden gebaut...

[Anonymous]

*hmpf*

Captain, in dem Augenblick wo Du es geschrieben hast war der MySQL wieder pfutsch. Weg ohne die leistete Fehlermeldung, jedoch nicht beendet, die Prozesse liefen noch. Also wird es der Server wohl auch bald wieder sein.

Also werd ich den MySQL nun auch noch neu bauen.
An irgend was muss es ja liegen ....

[Anonymous]

Moins zusammen ;o)


Also das Problem ist gelöst.

Es war tatsächlich die falsche Prozessorverwaltung im Kernel dafür verantwortlich. Der Server läuft nun ohne sich weghängen zu wollen.
Das Datenbank Problem ist auch nicht mehr existent, nachdem ich den unter PIII installierten MySQL deinstalliert habe und neu installiert habe. Jetzt aber unter dem mit PIIII kompilierten Kernel.

Meines Erachtens kann es nichts anderes gewesen sein, wenn am laufenden Bande zumindest da immer wieder Speicherzugriffsfehler gewesen sind.