Dienste schmieren immer wieder ab

matrix142

New Member
Guten Morgen,

in letzter Zeit habe ich ein Problem mit meinem Server.

Zuerst einmal zu den Daten:
- OpenSuse 10
- Plesk 10.1.1

Auf dem Server laufen Gameserver, deren Dienste in letzter Zeit vermehrt abschmieren. Meine Vermutung liegt dabei bei Apache.
An den Gameservern selbst liegt es nicht, denn die Log Dateien dort melden keine Fehler. Zudem passiert dies meist Nachts, wo die Gameserver sozusagen "leer laufen".

In der /var/log/apache2/error_log sind sehr viele "File does not exist"-Fehler zu finden, allerdings auch einige andere.

Ausschnitte der verschiedensten Fehler:
Code:
[Sun Mar 06 19:58:36 2011] [error] [client 72.68.78.19] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Mar 06 20:10:11 2011] [error] [client 62.141.45.70] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Mar 06 22:27:07 2011] [error] [client 109.230.251.30] File does not exist: /usr/share/apache2/error/vote
[Sun Mar 06 23:23:59 2011] [error] [client 109.230.246.172] File does not exist: /srv/www/vhosts/default/htdocs/config
[Mon Mar 07 05:00:41 2011] [error] [client 207.46.199.177] File does not exist: /srv/www/vhosts/default/htdocs/robots.txt
[Mon Mar 07 07:12:08 2011] [notice] caught SIGTERM, shutting down
[Mon Mar 07 07:27:05 2011] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Mon Mar 07 07:27:06 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)

Ich habe leider keine Ahnung, wie ich weiter vorgehen soll und hoffe, ihr könnt mir weiterhelfen.

Mit freundlichen Grüßen,
matrix142
 
Vserver, oder Rootserver?

Vom Logeintrag her könnte es sein, dass der Server neu gestartet wurde. Das würde natürlich bedeutet, dass Dienste wie Gameserver ebenfalls neu gestartet werden müssen.

Hast du einen Neustart zur fraglichen Zeit durchgeführt?

Wenn nein, rate ich mal in Blaue hinein, da du hier kaum Informationen bereitstellst:
Du hast einen Vserver, von Linux nicht sehr viel Ahnung und viel zu viele Dienste auf dem Vserver laufen. Dieser kommt nun an sein Recourcenlimit, wenn die Gameserver bespielt werden.
Als Folge dessen beendet die Virtualisierungssoftware den virtuellen Container und startet ihn neu. Alle Prozesse, die nicht im Autostart, bei Linux /etc/init.d/, eingetragen sind, werden bei dem Neustart natürlich nicht mit dem System gestartet. Der Anwender denkt nun, die Server sind abgestürzt.

Alternativ, oder ebenso kann es sein, dass der ganze Server automatisch neu startet.

Die nonexist Fehler kommen entweder daher, dass deine Webseiten schlampig geschrieben wurden und auf Dateien verweisen, die nicht existieren und oder Bots und Scanner arbeiten ein Schema X ab und versuchen auf Dateien zuzugreifen, die nicht vorhanden sind.
 
Last edited by a moderator:
Vserver, oder Rootserver?
Von der leidigen Diskussion abgesehen dass Rootserver eigentlich Server der DNS-Rootzone betitelt, kann ein vServer auch ein 'Rootserver' sein sofern man Superuser-Zugang hat ;)

Als Folge dessen beendet die Virtualisierungssoftware den virtuellen Container und startet ihn neu.
Nicht zwingend. Der Kernel kann auch Prozesse beenden wenn das Limit ueberschritten ist (allerdings afaik mit SIGKILL nicht SIGTERM) und Prozesse stuerzen oft durch fehlendes Fehlerhandling ab wenn ein malloc() erfolglos ist.

Auf dem Server laufen Gameserver, deren Dienste in letzter Zeit vermehrt abschmieren. Meine Vermutung liegt dabei bei Apache.
Ausser dass vServer fuer Gameserver absolut ungeeignet sind (siehe andere Threads der letzten Zeit fuer Erklaerungen) generiert Apache in allen Faellen nur Probleme wenn in Kombination mit Gameserver. Auslagern auf einen reinen Webspace!

Falls vServer:
Bitte `uptime` und `cat proc/user_beancounters` nach einem solchen Problem hier posten. (Kann sein dass letzteres eine Fehlermeldung wirft, in dem Fall das bitte angeben da du dann nicht unter OpenVZ/Virtuozzo bist)

Falls RootServer:
Was sagt die RAM-Belastung und /var/log/syslog ?
 
Danke schonmal für die zwei Antworten.

Vserver, oder Rootserver?
Es ist ein VServer.
Hast du einen Neustart zur fraglichen Zeit durchgeführt?
Zu dieser Zeit wurde kein Neustart durchgeführt.
Dieser kommt nun an sein Recourcenlimit, wenn die Gameserver bespielt werden.
Der Server kommt auch nicht an das Ressourcenlimit. Von 512MB Ram ingesammt, sind immer um die 220MB in Verwendung. Prozessor ist nur wenige Prozent, ~5%, ausgelastet.

Die nonexist Fehler kommen entweder daher, dass deine Webseiten schlampig geschrieben wurden und auf Dateien verweisen, die nicht existieren und oder Bots und Scanner arbeiten ein Schema X ab und versuchen auf Dateien zuzugreifen, die nicht vorhanden sind.
Gut, dann können wir die ja vorerst mal außer Acht lassen, denn diese sollten dann wohl nichts mit einem Absturz zu tun haben.

uptime
6:25pm an 11:01, 1 Benutzer, Durchschnittslast: 1,44, 1,88, 2,17

cat proc/user_beancounters

Mit freundlichen Grüßen,
matrix142
 
Last edited by a moderator:
Hätte man auch selbst drauf kommen können, das hat man davon, wenn man stur abtippt :D
Danke^^

Version: 2.5
uid resource held maxheld barrier limit failcnt
1608105: kmemsize 8870525 10298922 9223372036854775807 9223372036854775807 0
lockedpages 0 0 9223372036854775807 9223372036854775807 0
privvmpages 101713 140417 9223372036854775807 9223372036854775807 0
shmpages 944 2239 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 88 103 9223372036854775807 9223372036854775807 0
physpages 42015 80287 9223372036854775807 9223372036854775807 0
vmguarpages 0 0 9223372036854775807 9223372036854775807 0
oomguarpages 42024 80296 9223372036854775807 9223372036854775807 0
numtcpsock 53 65 9223372036854775807 9223372036854775807 0
numflock 10 17 9223372036854775807 9223372036854775807 0
numpty 1 1 9223372036854775807 9223372036854775807 0
numsiginfo 0 12 9223372036854775807 9223372036854775807 0
tcpsndbuf 1078424 2545504 9223372036854775807 9223372036854775807 0
tcprcvbuf 1443328 1693744 9223372036854775807 9223372036854775807 0
othersockbuf 224976 371784 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 196920 9223372036854775807 9223372036854775807 0
numothersock 140 172 9223372036854775807 9223372036854775807 0
dcachesize 193434 336162 9223372036854775807 9223372036854775807 0
numfile 3474 4261 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 58 58 9223372036854775807 9223372036854775807 0
 
Ups, da hatte ich tatsaechlich das Slash vergessen :eek:
Mein Fehler.

Laut uptime ist dein System 11 Stunden am laufen, war der letzte Fehler zirka um diese Zeit?
Was sagt /var/log/syslog um diesen Zeitraum?
 
Das sollte von der Uhrzeit ca. hinkommen. Heute morgen war auf jeden Fall alles offline.
Es ist durchaus möglich, dass ein Update seitens meines Hosters eingespielt wurde, allerdings bin ich es gewohnt, dass alle zu dieser Zeit laufenden Dienst nachher wieder gestartet wurden.

Zudem konnte ich das Problem in den letzten Tagen wie gesagt vermehrt beobachten, sodass die Ursache durch einen restart eigentlich ausgeschlossen werden kann, aber wieso sollte sich der Server Nachts einfach neustarten?

Mit freundlichen Grüßen,
matrix142
 
allerdings bin ich es gewohnt, dass alle zu dieser Zeit laufenden Dienst nachher wieder gestartet wurden.
Sofern dein Provider den Container stoppt nur die welche einen init.d oder ein cron @reboot Eintrag haben. Das einfrieren der Container ist eher selten da mit Problemen zu rechnen ist.

aber wieso sollte sich der Server Nachts einfach neustarten?
Frag am besten deinen Provider ob er in den Logs nachschauen kann?
Eventuell hat dein Provider eins dieser ach-so-tollen Systeme beigebaut welche sofern 1 Prozess den COntainer blockiert (zb logrotate) diesen neu starten, aber das kann dir der Support sagen.
 
Ich hatte zuvor ganz vergessen zu sagen, dass es die
/var/logs/syslog
bei mir nicht gibt.

Aber ich werde mal meinen Hoster anschreiben, ob der da irgendwas dazu sagen kann, bzw. die ganze Sache zuvor erst nochmal weiter beobachten.
 
Back
Top