Hallöchen zusammen,
ich hab nen kleinen Server hier auf der Arbeit, auf dem SuSE Linux 9.3 läuft.
Nun ist es so, dass die Maschine meist so 1-2 Wochen tadellos läuft, und dann irgendwann abstürzt.
Ich gehe von einem Absturz aus, da ich mich weder mit VNC noch mit SSH auf das Teil verbinden kann (Verbindungs-TimeOut). Auch pingen geht nicht mehr.
Ich schalte den Server dann immer brutal aus und wieder ein. Dann fährt er normal hoch und läuft auch wieder 1-2 Wochen, bis der nächste Crash kommt.
Das dumme ist, der Server sitzt in nem 19Zoll Rack, und aus Platzgründen kann ich zur Zeit keinen Bildschirm anschliessen, um eventuelle Fehlermeldungen auf dem Monitor zu sehen.
Könnt ihr mir sagen, welche LogDateien (und wo die stehen) interessant sind, um die Ursache für den Fehler zu finden?
Linux 15.070 Themen, 107.540 Beiträge
Ich weiss nicht, was es bei SuSE so alles an Spezialitäten gibt, aber grundsätzlich stehen alle Logs in /var/log
Von besonderem Interesse sind dabei die Dateien /var/log/messages und /var/log/syslog
Die Ausgabe von dmesg (Kernelmeldungen) kann noch Aufschlüsse geben, aber die werden in der Regel nach dem Booten nach /var/log/dmesg und später nach messages oder syslog geschrieben.
Falls der Server mal über ein Wochenende down sein kann, würde ich mal memtest drüberlaufen lassen.
Was heißt stürtzt ab ?
Welche Serveranwendungen laufen auf dem Server ?
Du kannst bei den Serveranwendungen einstellen das mehr mitprotokolliert wird. Das kann man in den Konfigurationsdateien einstellen.
Du mußt aber damit rechnen das die Logdateien in /var/log größer werden.
Programmierfehler wie Speicherlecks haben im Serverbereich fatale Folgen.
Das Programm reserviert Speicher auf dem Heap und gibt ihn aber nicht wieder frei (wegen eines Programmierfehlers).
Und irgendwann ist der Speicher voll.
Kontrollier mal die Ausgabe von free. Ist die gesamte Auslagerungspartition voll und überhaupt kein Speicher mehr frei ?
Das nächste was ich überprüfen würde ist die Ausgabe von ps oder top. Entstehen sehr viele Zombieprozesse ?
Und dann ist die Firewall sehr wichtig.
Es gibt mittlerweile sehr viele Hackertools wie den Portscanner nmap. Wenn man nmap falsch bedient, kann das Scannen eines Servers zum Absturtz führen.
Es gibt gibt immer wieder große und kleine Scriptkiddies die solche Hackertools einsetzen um die Server zum Absturtz zu bringen.
Check mal deine Firewall.
Und dann gibt es eventuell Hardwareprobleme.
Entweder du nutzt memtest wie the_mic schon schreibt oder du kompilierst ein paar mal irgendein Programm oder den Betriebsystemkern. SUSE hatte früher so einen Test mit dem Compiler gcc um die Stabilität der Hardware herauszufinden.
Man konnte diesen Test etwa 2 oder 3 Tage lang laufen lassen, nur um zu sehen das es keine Probleme mit dem Speicher oder dem Netzteil gibt.
Wenn die Hardware nicht stabil läuft löst der Linuxkernel ein Signal 9 oder 11 aus (oder ein anderes Signal) und beendet alle Prozesse, um Datenverlust zu verhindern.
Etwas trivial aber auch eine mögliche Ursache hinsichtlich voller Partitionen kann ein vergessenes bzw. nicht eingerichtetes logrotate sein, das "alte" logs komprimiert und irgendwann mal löscht, damit nicht /var/log überläuft.
Ich weiß nicht wie die Partitionierung ist. Normalerweise soll man ja Verzeichnisse wie /tmp und /var im Serverbereich auf eine eigene Partition legen. Damit soll verhindert werden, das durch das Vollaufen der Festplatte der Server abstürtzt.
Mir ist das noch nicht passiert und weiß ehrlich auch nicht wie eine Serveranwendung reagiert wenn /tmp oder /var voll sind.
Nur wenn die gesamte Festplatte voll ist wird wahrscheinlich auch das Betriebsystem sich verabschieden.
Guten Morgen zusammen,
danke für die Rückmeldungen. Nach der ersten Tasse Kaffee (also gleich) werde ich mir mal in aller Ruhe die Logs vornehmen.
Kann wohl etwas dauern, da ich hier auf der Arbeit bin, und schonmal ganz gerne mit Arbeit unterbrochen werde ;-)
@the_mic: der Server ist nicht im Produktivbetrieb. Der kann down sein wann immer ich will. Von daher kann das mit nem Memtest auch keine schlechte Idee sein. Setze ich mit auf die to-to Liste.
@KarstenW: Was heißt stürtzt ab ?
Nun, wie ich in meinem Ausgansposting geschrieben habe: Ich gehe von einem Absturz aus, da ich mich weder mit VNC noch mit SSH auf das Teil verbinden kann (Verbindungs-TimeOut). Auch pingen geht nicht mehr.
Da ich an dem Server zur Zeit keinen Bildschirm anschliessen kann, bin ich auf die TCP/IP Serverdienste angewiesen, um mich mit ihm zu verbinden. Ich muss in diesem Fall also von einem Absturz ausgehen, wenn http, ftp, vnc, ssh und smb down sind.
Okay, könnte auch nur die Netzwerkkarte sein, aber ich kann etwas anderes zur Zeit nicht testen.
Ein Problem mit der Firewall schliesse ich aus. Der Server hängt in einer Serverfarm von 15 Servern hinter einer Watchguard. Von aussen ist der aber auch gar nicht erreichbar. Das muss auch nicht sein. Auf dem Linux selber ist die Firewall abgeschaltet. Hier im hausinternen Netz brauche ich die nicht, da da eh keine kritischen Daten rumliegen. Lediglich eine Kopie unseres Internetauftrittes. Dort teste ich die Änderungen, bevor die auf die echte Homepage portiert werden.
Des weiteren kann ich sagen, dass dieser "Absturz" auftritt, wenn der Server im Leerlauf läuft, aber auch wenn die CPU Last bei 100% liegt. Ich lasse nämlich nebenbei nen SETI Client laufen.
@Cbuddeweg: Die Plattenbelegung liegt bei 21%. Daran wirds, denke ich nicht liegen.
Aber alles weitere wäre jetzt aber reine Spekulation. Ich werde mich jetzt gleich erstmal um die Logs kümmern.
Dann sehn wir weiter. Ich meld mich, wenn ich was gefunden hab, oder auch nicht ;-)
Danke soweit von mir.
Dann tippe ich auf einen Laufzeitfehler, also eventuell ein Speicherleck bei einem Programm. Seti auf einem Server ?
Bist du sicher das dieses Seti fehlerfrei programmiert ist und keine Speicherlecks drinnen sind ?
Auf einem Server wird immer nur ein Minimalsystem installiert. Es werden nur diejenigen Programme installiert die auch wirklich benötigt werden. Man muß immer damit rechnen das in irgendwelchen Programmen (XServer oder Desktop oder SETI ;-)) Programmierfehler sind, die dann wiederum von Hackern ausgenutzt werden oder die allgemein zu Abstürzen führen.
Man installiert deshalb auf einem Server nie einen XServer und auch keinen Desktop.
Ich würde auch mal einen eigenen Betriebsystemkern übersetzen und alle unnötigen Treiber rausnehmen. Ich habe da auch schon Probleme gehabt weil manche Treiber nicht richtig funktionieren und für meinen Rechner gar nicht gebraucht wurden.
Manchmal spinnt auch die Ramdisk rum. Ich würde an deiner Stelle den Linuxkernel neu übersetzen und alle notwendigen Treiber monolitisch kompilieren.
Warum nicht? Wie gesagt, es ist ja kein Produktivserver. Ich habe das Ding als Spielkiste zur freien Verfügung.
Bist du sicher das dieses Seti fehlerfrei programmiert ist und keine Speicherlecks drinnen sind ?
Woher soll ich das Wissen? Ich bin kein Programmierer.
Der BOINC Client ist von der offiziellen Homepage des Projektes heruntergeladen, und die Probleme mit dem Server hatte ich aber, wie schon gesagt, auch schon vorher.
Ich gehe erstmal weiter die Logs durch...
Selbst wenn du Programmierer wärst , würdest du nicht unbedingt den Programmierfehler finden.
Es gibt syntaktische Programmierfehler, logische Programmierfehler und Laufzeitfehler.
Die Laufzeitfehler sind am schwierigsten zu finden, weil wie der Name schon sagt sie erst bei längerer Laufzeit wie im Serverbereich auftreten.
Speicherlecks sind da nur eine Art von Programmierfehler.
Ich meine ja nur, bis du dir einen Wolf suchst in den Logdateien, würde ich mal alle unnötigen Programme deinstallieren oder eben nicht laufen lassen.
