Komische Serverabstürze

w3bservice

Member
Hallo, ich betreibe einen CentOS 7 Server mit ISPConfig 3 auf einem EX60 von Hetzner. Kernelversion 3.18-5 von elrepo, wobei die Corekernel von CentOS7 auch keine Schwierigkeiten machen.
Es gibt Zeiten da läuft der Server 14 Tage durch ohne irgentwas und dann stürzt er 3x in der Woche weg.
Sprich, der Webserver läuft noch und ich kann den Server anpingen.
SSH, FTP, Mail usw sind tot.
Man sieht in den Logs sehr schön sieht, greifen die Dienste ab 2:30 Uhr zwar auf das Verzeichnis /usr/lib64 zu aber bekommen ihre Dateien nicht zu fassen.
Auf em System sind 4 Partitionen angelegt. /boot /var /backup /.
Das ganze läuft im Raid mit einem LSI Megaraid 96xx 4i Raidcontroller.
Jeder Dienst der seine Bibliotheken unter /usr/lib64 hat greift dann ins Klo und fängt an zu zicken.
Sitze jetzt schon seit ein paar Wochen dabei den Fehler zu finden. Was sich schwierig erweisst, da er sehr sporadisch auftritt.
Ein gesendetes crtl+Alt+Entf über Robot von Hetzner oder der Laraconsole bringen nix. Ich muss entweder einen Automatischen Reset machen oder einen Admin hinlatschen lassen.
Einen Hardwarecheck habe ich letztes WE machen lassen, ohne Ergebnis. und wenn ich das System im Rsecuesystem hochfahre und das Dateisystem überprüfe werden keine Fehler angezeigt. Jedenfalls keine gravierenden, ausser die die durch den Hardreset entstehen.
 

Anhänge

  • serverlog.txt
    530,3 KB · Aufrufe: 1.347

nowayback

Well-Known Member
Hmmm in den Logs lässt sich auf Anhieb nichts finden was ein solches Verhalten erklären könnte.
Was sagt denn der freie Plattenplatz und die Anzahl geöffneter Dateien zu dem Zeitpunkt? Evtl. rennst du einfach in irgendein Limit.
 

w3bservice

Member
der virtuelle Speicher ist gerade in Benutzung da ich einen memtester laufen habe

48 GB 4 HT Prozessoren und 2 Platten je 2 Terrabyte im Raid gespiegelt.
 

Anhänge

  • dmesg.txt
    58,7 KB · Aufrufe: 383
  • Bildschirmfoto-577.png
    Bildschirmfoto-577.png
    163,6 KB · Aufrufe: 330

nowayback

Well-Known Member
memtester im virtuellen speicher? was soll das bringen?
Dein screenshot sagt leider nichts über den freien speicher der einzelnen partitionen und auch nicht über geöffnete dateien und dein dafür eingestelltes limit. die durchschnittliche cpu last von 7,86 ist nahe am maximum.
 

w3bservice

Member
Es lief memtester......durchschnittlich 10% Last auf Prozessoren und Speicher sind normal auf dem Server.
War ne blöde Idee den memtester laufen zu lassen, wenn der Server arbeitet.
Plattennutzung ca 45% runde 300 Prozesse die laufen.
 

piet

New Member
Ich kenne den Aufbau Deiner Anlage nicht, läuft das Ganze übers Netz? Passiert das immer nachts? Die Probleme bei der Authentifizierung sehen mir so aus, als ob die Verbindung unterbrochen wurde.

Wir hatten ähnliche Sachen mit Copies über ein vpn, weil die beteiligten Router erzwungenerweise nachts neue ips gezogen haben und dann eine zeitlang nicht erreichbar waren. Wenn das wirklich der Fall sein sollte, könnte ich vielleicht mit ein paar kleinen Scripts aushelfen. Als workaround bis zur Fehlerbehebung würde ich empfehlen per cron-job die entsprechenden services zu überwachen und neu zu starten wenn nötig, damit Dein Server zumindest erreichbar bleibt (auch da gäbe es fertige scripts). Einige Dienste reagieren empfindlich, wenn man ihnen die Verbindungen unter dem Hintern wegtauscht bzw. bei Nutzung eines vpns längere Verzögerungen dadurch entstehen.

Ich konnte nur flüchtig über Dein Log schauen, kann sein, dass ich daneben liege. Einen Gedanken ist es zumindest wert. Nicht das Du an der falschen Stelle suchst.
 

w3bservice

Member
Die Abstürze passieren sporadisch.....3 mal am Tag und dann 14 Tage gar nichts. Das Problem ist, das jeder Dienst der auf Pam zugreift ins Klo greift. Die Pambibliotheken unter /usr/lib64 sind nicht lesbar bzw. permission denied.
Nur SMTP...POP3/IMAP und SSH......Datenbankserver und Webserver laufen weiter.
Um das ganze einzugrenzen, da die Logs auch nichts ausgesagt haben ausser das die Dienste nicht auf Pam zugreifen können und es teilweise Lücken von mehreren Stunden entstanden sind wo nicht geloggt wurde, habe ich vor 3 Wochen einen Hardwaretest machen lassen. Und die Admins von Hetzner haben in Ihrer Weisheit keinen Speichertest gemacht. Speicher gehört ja nicht zur Hardware.......
_______________________________________________________________________________________________

Linux rescue 3.14.27 #56 SMP Mon Jan 5 13:49:20 CET 2015 x86_64

-------------------------------------------------------------------

Welcome to the Hetzner Rescue System.

This Rescue System is based on Debian 7.0 (wheezy) with a newer
kernel. You can install software as in a normal system.

To install a new operating system from one of our prebuilt
images, run 'installimage' and follow the instructions.

More information at http://wiki.hetzner.de

-------------------------------------------------------------------

/usr/bin/xauth: file /root/.Xauthority does not exist
Hardware data:

CPU1: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz (Cores 8)
Memory: 48302 MB
Disk /dev/sda: 1999 GB (=> 1862 GiB)
Total capacity 1862 GiB with 1 Disk
RAID LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator]

Network data:
eth0 LINK: yes
MAC:
IP:
IPv6:

root@rescue ~ # memtester
memtester version 4.2.2 (64-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
need memory argument, in MB

Usage: memtester [-p physaddrbase] <mem>[B|K|M|G] [loops]
root@rescue ~ # memtester 48302MB
memtester version 4.2.2 (64-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 48302MB (50648317952 bytes)
got 47766MB (50087301120 bytes), trying mlock ...Killed
_____________________________________________________________________________________________
536 MB von den 48 GB gingen ab, da nach einem Speichertausch folgende Meldung war

memtester version 4.3.0 (64-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
need memory argument, in MB

Usage: memtester [-p physaddrbase] <mem>[B|K|M|G] [loops]
root@rescue ~ # memtester 48302MB
memtester version 4.3.0 (64-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 48302MB (50648317952 bytes)
got 48304MB (50648317952 bytes), trying mlock ...Killed

Ich denke das Problem hat sich damit gelöst.
Irgentwann war der Server der Meinung auf den defekten Speicher zugreifen zu müssen und damit ging das System baden.

Ich danke Euch für Eure Hilfe und Vorschläge.
 

w3bservice

Member
So der Speicheraustausch hatte nichts gebracht. In der Nacht vom Freitag zum Samstag wurde die Hardware getauscht, so das nur der Raidcontroller und die beiden Platten aus dem Server übrig blieben. Mal abgesehen, das es die Admins nicht interessiert hatte das der Server schon herruntergefahren war und man mir mit einem Hardreset die Datenbanken zerschossen hat, brachte es auch das nichts. Bleibt ja jetzt nicht mehr viel übrig. So und jetzt werde ich mich mal ganz langsam mit Debian anfreunden und den neuen Server damit aufsetzen. Das einzige was ich herausbekommen habe, das die Server bei Hetzner Dell-Server sind und es wohl Probleme seit dem Kernel 3.10 und der binären Firmware von Dell gibt. Ich habe einige Server mit CentOS7 aufgesetzt, auf IBM-Kisten, Fijutsiu, HP....in der gleichen Konfiguration und keine Probleme. Also werde ich jetzt noch den Versuch über die Kernelconsole machen, und per UDP die Daten auf einen anderen Server blasen. Wenn dabei nichts rauskommt, war es dass. Jetzt habe ich mich schon so an SystemD und firewalld-cmd gewöhnt........;)
 

w3bservice

Member
So das Problem gelöst, Hetzner in Ihrer Weisheit hatten nur einen Lüfter im System.
Bei 57% Systemlast gingen die Prozessoren auf fast 90 Grad hoch. Nach dem 2 zusätzliche Lüfter eingebaut wurden hatte sich dies dann erledigt. Wnn es mal zu warm wird, ändert sich der elektrische Widerstand der Bauteile und Leiterbahnen, und dann kann es schon passieren, das mal ein Bit umkippt und es zu so einer Kettenreaktion kommt.

Das Thema kann geschlossen werden.

Danke Euch allen für die Hilfe
 

Werbung

Top