PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Server ständig down



Gorn
22.06.05, 08:03
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.

mbo
22.06.05, 08:19
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

Gorn
23.06.05, 14:21
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.

Jasper
23.06.05, 14:42
Und dann kommt nichts mehr.

nach einem kernel-panic kommt i.d.R. auch nichts mehr.
check mal komplett alle filesysteme durch.


-j

Gorn
24.06.05, 10:22
oh - k.

Welche tool schlägst Du vor? fsck ist nicht so dolle wenn das Device gemountet ist.

majobu
24.06.05, 10:32
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

rudi_m
24.06.05, 10:48
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

Gorn
24.06.05, 11:14
jop - es dürfte wohl das script sein.. ich lese mir aber nochmal alles genau durch.

Jasper
24.06.05, 17:39
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

basstscho
25.06.05, 17:19
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