PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : out of memory - killed http ???



laminar
26.01.03, 11:27
das war die fehlermeldung meines servers nach dem reboot. in der errorlog fand sich folgendes:
[Sat Jan 25 10:38:30 2003] [warn] child process 28875 still did not exit, sending a SIGTERM
[Sat Jan 25 10:38:34 2003] [crit] (98)Address already in use: make_sock: could not bind to port 443

hängt das irgendwie zusammen und was sagt uns das ? diese uhrzeit war nicht die uhrzeit
zu der sich der server verabschiedet hat, muss irgendwann nachts passiert sein..

Jasper
27.01.03, 09:48
Original geschrieben von laminar
das war die fehlermeldung meines servers nach dem reboot. in der errorlog fand sich folgendes:
[Sat Jan 25 10:38:30 2003] [warn] child process 28875 still did not exit, sending a SIGTERM
[Sat Jan 25 10:38:34 2003] [crit] (98)Address already in use: make_sock: could not bind to port 443

hängt das irgendwie zusammen und was sagt uns das ? diese uhrzeit war nicht die uhrzeit
zu der sich der server verabschiedet hat, muss irgendwann nachts passiert sein..

apache hat sich so viel speicher genommen, dass der kernel eine OOM-kill gemacht hat. und da httpd der prozess mit dem meisten speicher war, wurde eben dieser gekillt. über die ursache lässt sich nur spekulieren, da man dazu das system sich näher ansehen muss. die beiden obigen meldungen nützen nichts, da man nicht weiss, ob sie nach oder vor dem oom-kill aufgetreten sind.

-j

laminar
27.01.03, 11:41
würdest du schauen, um mehr heraus zu bekommen ?

Jasper
27.01.03, 14:00
Original geschrieben von laminar
würdest du schauen, um mehr heraus zu bekommen ?

in alle logfiles, die mit dem problem zu tun haben könnten. die namen der logfiles hängen von deiner syslog-konfiguration ab. bei mir heissen die z.b. /var/log/messages und /var/log/kernel.
dann die logfiles des apache um zu sehen, was für requests kamen zu dem zeitpunkt rein. falls eine datenbank mit involviert ist, auch deren logfiles.

auf jeden fall musst du zuerst den zeitrahmen feststellen, in dem das problem auftrat, also z.b. wann der oom-kill auftrat. dann langsam nach hinten durcharbeiten und nach auffälligkeiten ausschau halten.
wenn du sar verwendest, dort auch reinschauen um herauszufinden, wie und wann die systemlast anstieg.

-j

laminar
27.01.03, 15:59
mal sehen, was ich davon finde...