s4y System Crashes seit Stromausfall

  • Thread starter Thread starter Deleted member 4401
  • Start date Start date
D

Deleted member 4401

Guest
Seit dem Stromausfall crashen alle meiner 3 RootDS mit schöner regelmässigkeit (alle paar Tage), alle mit "memory allocation problems". Die Server liefen alle seit Monaten mit unverändererter Konfiguration ohne Probleme, und in den Logs lassen sich (ausser evtl. ein paar Portscans) keinerlei Hinweise auf den Grund finden.
Jemand die gleichen Probleme? Ich meine, das kann doch kein Zufall sein....:confused:

Code: 
Jul 26 09:22:01 serv /USR/SBIN/CRON[22526]: (root) CMD (   run-parts --report /etc/cron.hourly)
Jul 26 09:30:01 serv /USR/SBIN/CRON[3451]: (root) CMD ( /usr/local/confixx/confixx_counterscript.pl)
Jul 26 09:39:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 09:40:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 09:50:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:00:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:09:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:10:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:20:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:22:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:30:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:40:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 10:50:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 11:00:01 serv /usr/sbin/cron[10185]: (CRON) error (can't fork)
Jul 26 11:01:57 serv inetd[9822]: accept (for pop3): Cannot allocate memory
Jul 26 11:02:10 serv inetd[9822]: accept (for pop3): Cannot allocate memory
 
Code: 
VPS Speichernutzung:
Momentan genutzt:       343.344 MB
Maximal genutzt:        619.352 MB
Zugesichert:            640 MB
Maximal nutzbar:        1344 MB
Der Wert für die maximale Nutzung ist ziemlich hoch, allerdings sollte das meiner Meinung nach noch kein Grund für das Speicherproblem sein. Dieser Wert trat beim letzten Crash auf bei dem ich noch die Chance hatte mich vorher einzuloggen, üblicherweise bleibt der Wert unter 400MB. Die Serverlast lag dabei auf 25 (!) und es hagelte Fehlermeldungen, z.B. dass /proc nicht gemountet wäre beim Versuch netstat abzufragen.
 
Last edited by a moderator:
Öhm, gehe ich recht in der Annahme dass es diese Kleinigkeit ist:
147180
240091
:)
 
Vielleicht solltest du mal über den Einsatz von "ServerLimit" in deiner Apache Config nachdenken.
Bei der Tortur die dein Apache gestern Mittag erdulden musste, könnte man vielleicht auch über mod_evasive nachdenken. ;)
 
Danke für die schnelle Antwort.

Hm, also mod_evasive läuft schon auf beiden Servern, allerdings in der default config:
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10

Ist es bei prefork nicht relativ nutzlos ServerLimit zu setzen da es ja nur die theoretisch höchstmögliche Anzahl von MaxClients in der config vorgibt? Oder habe ich da was missverstanden und ServerLimit gibt auch bei prefork die max. Anzahl an Prozessen vor?
 
Last edited by a moderator:
Ich möcht bewusst keinen konkreten Wert nennen, dafür kenne ich deine Config zu wenig. Aber das kannst du auch recht leicht austesten:

Setz mal ein Limit bei 30 und beobachte deine UBC Werte. Apache bietet ein Benchmark Tool an "ab", mit dem du den Apache etwas stressen kannst. Benchmark aber über localhost auf den Webserver verbinden lassen und localhost in die Whitelist von mod_evasive aufnehmen, bzw. für die Zeit des Tests mod_evasive abschalten.

Wenn sich zeigt das Ressourcen übrig bleiben, kannst du die Limits etwas höher schrauben. Bedenke nur das du dabei nicht bis ans ultimative Limit des Servers gehst, denn es gibt noch mehr Dienste die Ressourcen haben wollen.
MySQL, MTA, Spamfilter, diverse Scripte, Cronjobs usw. sind alles Sachen die zu unterschiedlichen Zeitpunkten unterschiedlich viel Ressourcen brauchen.

Eine gute Serverkonfiguration erzeugt man in den meisten Fällen nicht auf anhieb, die entwickelt sich mit der Zeit. ;)

Jaein, wenn man davon absieht, das auch dein MaxClients zu hoch ist, bevorzuge ich immer beides zu definieren. Insbesondere dann wenn man von den 256 stark abweichen möchte. ;)
Sollte Apache mal einen Bug mit MaxClients haben, könnte man sich dann immer noch aufs ServerLimit verlassen ohne das es gleich in einer Katastrophe endet. Gibt einfach zusätzliche Sicherheit das der Wert nicht überschritten wird. Beides auf den gleichen Wert setzen und gut.

Im übrigen empfehl ich dir ein locales Monitoring der Anzahl der Prozesse, Speicherauslastung, usw einzurichten. Falls es doch nicht der Apache sein sollte, kannst du es beim nächsten mal wenigstens direkt dem verursacher zuordnen.
Ein einfaches Bash Script (per Cronjob ausgeführt) was die Werte ausliest und in ein Log schreibt sollte hierfür reichen.
 
Vielen Dank für die ausführliche Antwort und die Tips, werde ich schnellstmöglich in die Tat umsetzen.
Ich muss zugeben dass ich mein Hauptaugenmerk auf die Absicherung gelenkt hatte und dadurch die Performance-Optimierung (vor allem in Sachen Apache) wohl ein wenig habe verkümmern lassen...also ziehe ich den schwarzen Peter gegen S4Y zurück und schiebe ihn mir mal selbst in die Schuhe..;)
 
Da du der einzigste auf dem Hostsystem bist der solche Probleme hat, liegt eine Fehlkonfiguration recht nahe. ;)
Zumal dein Apache noch nicht mal sooo schlecht konfiguriert ist, da gibts durch aus schlimmeres. :)

Das mit dem Apache ist im übrigen nur eine Vermutung, weil im nachhinein kann man ohne Monitoring schlecht feststellen, welcher Prozess nun genau die Ressourcen verbraten hat. Deshalb auch der Rat für das Ressourcen und Prozess Monitoring.
 
Nun ja, jetzt hat die Spekulation leider ein Ende, bitte PM lesen.
 
Ok, Situation wieder unter Kontrolle, herzlichen Dank an Firewire2002 für den Versuch auf unkonventionelle Weise zu helfen. :)
 
Als Abschluss sollte man vielleicht noch erwähnen, woran es nun lag:
Meine Vermutung war richtig. Der Apache stand unter Beschuss. ;)
 
Yep, das Botnet bestand aus etwas mehr als 100 Zombies....manchen muss echt langweilig sein. :rolleyes:
 
You must log in or register to reply here.
Back
Top