Archiv verlassen und diese Seite im Standarddesign anzeigen : Server ständig down
Hallo Leute,
also wir haben einen Debian Websever laufen. Alle x-Tage fällt der plötzlich aus.
1. Ping geht.
2. shh, Apache usw. geht alles nicht mehr.
Wir können den Server dann nur noch durch Hardreset neu starten. Leider kann ich in den log files nichts! finden, warum da die Daemons abschmieren.
Was mir aber aufgefallen ist:
Jun 12 06:47:06 XXXXXXX PAM_unix[9505]: (cron) session closed for user root
Jun 12 06:48:01 XXXXXXX PAM_unix[10096]: (cron) session opened for user root by (uid=0)
(XXXXXX = ip)
Dies steht in der auth.log - und zwar jede Stunde... was macht PAM da? Ich kann den Cronjob nicht finden.
2. shh, Apache usw. geht alles nicht mehr.
nicht ein port mehr offen?
Leider kann ich in den log files nichts! finden, warum da die Daemons abschmieren.
Das vielleicht nicht, aber andere Fehler / Meldungen u.U.
EIn Blick auf die letzten Minuten wäre interessant. Je nachdem wie er stirbt,kann es durchaus sein, daß der logger auch mit- und als erstes stirbt. Aber die Kontinuität und Zuverlässigkeit verdächtigen meist Kernel und / oder Hardware.
Jun 12 06:47:06 XXXXXXX PAM_unix[9505]: (cron) session closed for user root
Jun 12 06:48:01 XXXXXXX PAM_unix[10096]: (cron) session opened for user root by (uid=0)
Mr. Cron, der root spielt, weil er Jobs zu tun hat.
cu/2 iae
ich glaube das es was mit den Kernel ist... folgende Zeilen sagen was dazu:
syslog
Jun 15 16:04:01/USR/SBIN/CRON[20317]: (root) CMD (/root/confixx/confixx_counterscript.pl)
Jun 15 16:04:02kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
Jun 15 16:04:02kernel: printing eip:
Jun 15 16:04:02kernel: c0143920
Jun 15 16:04:02kernel: *pde = 00000000
Jun 15 16:04:02kernel: Oops: 0000
Jun 15 16:04:02kernel: CPU: 0
Jun 15 16:04:02kernel: EIP: 0010:[d_lookup+96/256] Not tainted
Jun 15 16:04:02kernel: EFLAGS: 00010213
Jun 15 16:04:02kernel: eax: f7f8c0a8 ebx: fffffff0 ecx: 00000011 edx: 002524ba
Jun 15 16:04:02kernel: esi: 00000000 edi: c2bfbfa4 ebp: 00000000 esp: c2bfbf04
Jun 15 16:04:02kernel: ds: 0018 es: 0018 ss: 0018
Jun 15 16:04:02kernel: Process confixx_counter (pid: 20317, stackpage=c2bfb000)
Jun 15 16:04:02kernel: Stack: c2bfbf64 00000000 c2bfbfa4 f7c52630 f7f8c0a8 c2c7f005 002524ba 00000003
Jun 15 16:04:02kernel: c013ae42 c1bf97b0 c2bfbf64 c2bfbf64 c013b5e0 c1bf97b0 c2bfbf64 00000000
Jun 15 16:04:02kernel: c2bfbfa4 c2c7f000 00000000 00000008 0813ddc8 00000008 c2c7f008 00000000
Jun 15 16:04:02kernel: Call Trace: [cached_lookup+14/80] [link_path_walk+1448/2084] [path_walk+26/28] [path_look$
Jun 15 16:04:02kernel: [sys_lstat64+25/112] [sys_close+67/84] [system_call+51/56]
Jun 15 16:04:02kernel:
Jun 15 16:04:02kernel: Code: 8b 6d 00 8b 54 24 18 39 53 44 75 7c 8b 44 24 24 39 43 0c 75
Und dann kommt nichts mehr.
Und dann kommt nichts mehr.
nach einem kernel-panic kommt i.d.R. auch nichts mehr.
check mal komplett alle filesysteme durch.
-j
oh - k.
Welche tool schlägst Du vor? fsck ist nicht so dolle wenn das Device gemountet ist.
Ich sehe das dort Confixx drauf ist und vermute mal das du einen Rootserver hast. Den solltest du in der Rettungskonsole starten und von dort aus die Filesysteme checken.
Wenn das kein Rootserver ist, dann verwendest du der Einfachheit am besten Knoppix und machst den Check von dort aus...
Gruß
majobu
Das ist keine Kernelpanic sondern nur ein oops
Du kannst ihn mit "ksymoops" auswerten und erfaehrst vielleicht mehr.
Moeglicherwisse laeuft confixx (oder was anderes) amok und verbraet den ganzen RAM. Dann faengt der rechner an zu swappen und wird unendlich langsam (ping geht vielleicht gerade noch)
Es kann dann eine weile dauern bis der Kernel den schuldigen Prozess automatisch killt.
Ich hatte mal so ein Problem mit einem php script auf dem apache!
Ich wuerde Dir empfehlen den RAM/swap Bedarf regelmaessig zu beobachten oder auch in kurzen intervallen mitzuloggen.
schau mal in den logs ob die vorigen oops auch direckt nach dem CRON job kamen
Jun 15 16:04:01/USR/SBIN/CRON[20317]: (root) CMD (/root/confixx/confixx_counterscript.pl)
Jun 15 16:04:02kernel: <1>Unable to handle kernel NULL pointer dereference at virtual addre
jop - es dürfte wohl das script sein.. ich lese mir aber nochmal alles genau durch.
Moeglicherwisse laeuft confixx (oder was anderes) amok und verbraet den ganzen RAM. Dann faengt der rechner an zu swappen und wird unendlich langsam (ping geht vielleicht gerade noch)
Es kann dann eine weile dauern bis der Kernel den schuldigen Prozess automatisch killt.
OMG, das ist kein OOM-kill sondern eine nullpointerdereferenz im kernel! irgendwelche userspace-prozesse haben damit null zu tun.
hier nochmal schön aufgedröselt:
prozess confixx_counter mit pid 20317 ist gerade aktiv:
Jun 15 16:04:02kernel: Process confixx_counter (pid: 20317, stackpage=c2bfb000)
und hat einen system-call abgesetzt:
Jun 15 16:04:02kernel: [sys_lstat64+25/112] [sys_close+67/84] [system_call+51/56]
bei dessen ausführung in der funktion cached_lookup
Jun 15 16:04:02kernel: Call Trace: [cached_lookup+14/80] [link_path_walk+1448/2084] [path_walk+26/28] [path_look$
eine nullpointerdereferenzierung
Jun 15 16:04:02kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
auftrat. und cached_lookup ist eine vfs-komponente:
$ egrep -rl cached_lookup *
fs/namei.c
fs/nfs/dir.c
irgendwas korrumpiert den dcache. und deshalb würde ich als erstes die filesysteme durchchecken. wenn die ok sind, weiter zum ram, weil der cache bekanntlich im ram liegt.
hoffe, das jetzt alles klar ist.
-j
Hi, für solche Sachen ist hotsanic immer schön geeignet...das habe ich bald auf jedem Server laufen, braucht net viel resourcen und man sieht halt schön, was der Server so macht... (ich lass immer Traffic, Partitionen und die Systemdaten anzeigen)
http://hotsanic.sourceforge.net
Grüße Johannes
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.