I'm seeing the same thing with the prefork mpm under linux with lots of load.
Possibly it
is something outside of the mpms themselves? The processes definitly don't go away
until
you kill them with SIGKILL a few times. One thing I noticed is that, under load,
processes
seem to spend a lot of time in the 'close connection' state. By the time you have to
issue
the kills, mod_status shows idle children. Perhaps there is something that is not
getting
cleaned up properly?
On a possibly related note, I am seeing segfaults in prefork children under load when
the
number of children is high (over 1000). The stacktrace looks like so and doesn't make
a lot of sense:
#0 pthread_sighandler (signo=11, ctx=
{gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0,
edi = 1076506184, esi = 0, ebp = 3221223720, esp = 3221223680, ebx = 1076516568, edx =
1, ecx = 0, eax = 0, trapno = 13, err = 0, eip = 1076467940, cs = 35, __csh = 0,
eflags = 66070, esp_at_signal = 3221223680, ss = 43, __ssh = 0, fpstate = 0xbffff680,
oldmask = 2147483648, cr2 = 0}) at signals.c:87
87 signals.c: No such file or directory.
in signals.c
(gdb) where
#0 pthread_sighandler (signo=11, ctx=
{gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0,
edi = 1076506184, esi = 0, ebp = 3221223720, esp = 3221223680, ebx = 1076516568, edx =
1, ecx = 0, eax = 0, trapno = 13, err = 0, eip = 1076467940, cs = 35, __csh = 0,
eflags = 66070, esp_at_signal = 3221223680, ss = 43, __ssh = 0, fpstate = 0xbffff680,
oldmask = 2147483648, cr2 = 0}) at signals.c:87
#1 <signal handler called>
#2 __pthread_reset_main_thread () at internals.h:372
#3 0x402990e5 in __fork () at ptfork.c:92
#4 0x0809b2cd in ap_graceful_stop_signalled () at eval.c:41
#5 0x0809b643 in ap_graceful_stop_signalled () at eval.c:41
#6 0x0809ba62 in ap_mpm_run () at eval.c:41
#7 0x080a24ee in main () at eval.c:41
#8 0x402c2177 in __libc_start_main (main=0x80a1b9c <main>, argc=1, ubp_av=0xbffffb44,
init=0x80637a8 <_init>,
fini=0x80c2f50 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffb3c) at
../sysdeps/generic/libc-start.c:129
Anyone have an idea how to track this down? The ap_graceful_stop_signalled function
does *nothing* in the prefork mpm.
-adam
On Mon, Feb 04, 2002 at 02:13:52PM -0500, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> This was with the worker MPM.. I initially suspected the latency - 'waited
> for about 5 minutes, and then nothing happened till I issued a "kill -9"
> command. I'll try again today, and will probably post the stack trace of the
> parent process when it happens.
>
> Thanks
> -Madhu
>
> -----Original Message-----
> From: Greg Ames [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 9:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: 2.0.31 shutdown after heavy load
>
>
> "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" wrote:
> >
> > Hi,
> > I'm getting the following message when I try to stop apache after
> a
> > stress-test on HPUX (using webstone).. Inspite of the SIGKILL message, the
> > process does not exit.. A second attempt is successful.. Any clues
> regarding
> > what may be happening is appreciated..
> >
> > [error] child process 5891 still did not exit, sending a SIGKILL.
>
> which MPM? and have you tried this test with different results before?
>
> I didn't think we could do anything to block SIGKILL. Could this be just
> dispatching latency?
>
> Greg
--
"I believe in Kadath in the cold waste, and Ultima Thule. But you
cannot prove to me that Harvard Law School actually exists."
- Theodora Goss
"I'm not like that, I have a cat, I don't need you.. My cat, and
about 18 lines of bourne shell code replace you in life."
- anonymous
Adam Sussman
Vidya Media Ventures
[EMAIL PROTECTED]
