You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Graham Dumpleton <gr...@dscpl.com.au> on 2005/11/22 06:37:49 UTC
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Sorry, a couple more questions.
When you kill the child process, is Apache under load, ie., receiving
lots of requests or in an idle state with no requests being received?
Also, do you get the same results if you set "StartServers" to 2 and
kill off only one child process?
If you only have one child process and kill it, and lots of requests are
coming in, am wandering if Apache gets confused, thinking that the newly
spawned child process isn't ready and thus it decides to start a new
one. If this were happening but you have "StartServers" at 2 to begin
with such that you always have at least 1 child process even when you
kill off one of the originals, all those requests coming in would get
bumped off to the remaining child process and Apache may decide
not to create additional child processes.
Hope you can see what I am thinking.
Graham
Michel Jouvin wrote ..
> Graham,
>
> Sorry for the ambiguity. With worker MPM, the max number of process is
> the
> max number of threads divided by the number of thread per process. My
> config is :
>
> # worker MPM
> # StartServers: initial number of server processes to start
> # MaxClients: maximum number of simultaneous client connections
> # MinSpareThreads: minimum number of worker threads which are kept spare
> # MaxSpareThreads: maximum number of worker threads which are kept spare
> # ThreadsPerChild: constant number of worker threads in each server process
>
> <IfModule worker.c>
> MaxClients 245
> StartServers 1
> MinSpareThreads 5
> MaxSpareThreads 10
> ThreadsPerChild 35
> </IfModule>
>
> In our case that means that one process can handle 35 requessts and
> normally we have only one httpd slave running.
>
> After mod_python receives a signal like KILL or SEGV (in fact anything
> except TERM or HUP if I am right, you can test with kill command), I have
> 8 httpd slave processes and the following message in main Apache error
> log
> file :
>
> [error] server reached MaxClients setting, consider raising the MaxClients
> setting
>
> The only solution is to stop and start (not graceful restart) Apache.
>
> Cheers,
>
> Michel
>
> --On lundi 21 novembre 2005 19:28 -0500 Graham Dumpleton
> <gr...@dscpl.com.au> wrote:
>
> > Michel Jouvin wrote ..
> >> Hi,
> >>
> >> I recently installed mod_python 3.2b5 on Apache 2.0.54. I am running
> with
> >> problems if httpd slave process segfaults or is killed. In this case,
> >> master process restart the max number of processes/threads. We are
> >> running Apache with the MPM worker (on Tru64 platform).
> >>
> >> This behaviour appears only if mod_python is loaded into Apache. this
> >> doesn't seem to be related to mod_python usage : this can happen if
> you
> >> load mod_python even if no URL is configured to use it. You can easily
> >> reproduce the problem by doing 'kill -KILL' of an Apache slave process.
> >>
> >> Is it a known issue ? Are they any workaround ?
> >
> > What settings do you have in Apache config for:
> >
> > <IfModule worker.c>
> ># StartServers 2
> > StartServers 1
> > MaxClients 150
> > MinSpareThreads 25
> > MaxSpareThreads 75
> > ThreadsPerChild 25
> > MaxRequestsPerChild 0
> > </IfModule>
> >
> > Can you then relate your problem to your configuration with actual
> > numbers?
> >
> > Note that with "worker" configuration, there isn't generally a
> > MaxSpareServers or MinSpareServers setting as I understand, that is for
> > prefork only.
> >
> > <IfModule prefork.c>
> > StartServers 5
> > MinSpareServers 5
> > MaxSpareServers 10
> > MaxClients 150
> > MaxRequestsPerChild 0
> > </IfModule>
> >
> > So not sure when you say that it creates maximum number of processes
> > what you are exactly talking about. I might expect it to create number
> > of processes as specified by StartServers.
> >
> > Thus, can you please clarify.
> >
> > Graham
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
Hi,
I managed to find some time and rebuild mod_python after fixing the problem
of macro conflict between standard includes included by mod_python and the
same includes included by Python.h.
The problem is that Python.h defines a few macros used by standard includes
to non standard values (if I remember correctly this comes from BerkelyDB
includes). Thus it is important to have these macros defined before
including any standard .h. An easy workaround is to always include Python.h
before any other include. The files that need to be modified are :
./src/include/mod_python.h
./src/include/psp_parser.h
./src/_pspmodule.c
./src/psp_parser.c
./src/mod_python.c
May be this could be included in the standard distribution (I can provide
diff files but this is so easy to do..).
This doesn't solve the issue with starting a new child. I'll try to put
some additional logging messages in mod_python.c
Michel
--On samedi 10 décembre 2005 09:37 +0100 Michel Jouvin
<jo...@lal.in2p3.fr> wrote:
> Graham,
>
> No I am not using any PythonImport directive neither on the prod server,
> nor on the test server. On the test server, the only mod_python related
> directive is :
>
> LoadModule python_module modules/mod_python.so
>
> I'll try you suggestion about adding some logging messages in
> mod_python.c. By the way, I just remember that I had one problem to build
> mod_python on Tru64 with the native compiler (not tried with gcc) because
> of definition conflict for macro _XOPEN_SOURCES defined by Phyton
> pyconfig.h. The problem is that mod_python includes types.h without this
> macro defined to the value used by Python and before including pyconfig.h
> (Python.h). My hack was pretty dirty : undefine this macro in pyconfig.h
> to build mod_python successfully. But may be it is responsible for this
> side effect (unfortunatly this seems the only one...).
>
> I'll try to find the time to check this in the coming days...
>
> Michel
>
> --On samedi 10 décembre 2005 15:00 +1100 Graham Dumpleton
> <gr...@dscpl.com.au> wrote:
>
>> Just to make sure, are you using PythonImport directive at all? Want to
>> eliminate
>> this as these get run regardless of whether a request against a
>> mod_python
>> handler is received. If the code associated with PythonImport took some
>> time
>> to run, that might be a contributor.
>>
>> Anyway, not sure what else to suggest. I would probably start adding
>> extra
>> logging calls in the mod_python.c file of mod_python so that one could
>> see when
>> the Apache child process init function for mod_python is entered and
>> exited for
>> each process ID. That way could see if that is returning quickly or
>> taking some
>> time.
>>
>> Graham
>>
>> On 10/12/2005, at 10:38 AM, Michel Jouvin wrote:
>>
>>> I am still fighting with my mod_python problem on Tru64. I have
>>> been able to set up a test configuration with just standard Apache
>>> modules and mod_python loaded (no php, no dav, no subversion...)
>>> and without any url activating a mod_python handler.
>>>
>>> The problem remains the same. Just after starting Apache, with no
>>> request received by this server, I 'kill -KILL' httpd slave and
>>> this leads to the restart of other children that don't succeed to
>>> initialize properly. Apache restarts as many children as it can
>>> before giving up when it reaches MaxClients.
>>>
>>> Any idea on how to troubleshoot this and get any useful information
>>> to debug this problem ?
>>>
>>> Thanks in advance.
>>>
>>> Michel
>>>
>>> --On jeudi 24 novembre 2005 23:43 +0100 Michel Jouvin
>>> <jo...@lal.in2p3.fr> wrote:
>>>
>>>
>>>> Jim,
>>>>
>>>> I am not totally surprised... I am afraid this is a platform specific
>>>> issue as we are running mod_python on Tru64. Something like a 64 bits
>>>> issue. Does it sound a reasonnable possibility ? How to progress in
>>>> troubleshooting ?
>>>>
>>>> Michel
>>>>
>>>> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
>>>> <jp...@jgassociates.ca> wrote:
>>>>
>>>>
>>>>> Michel,
>>>>>
>>>>> I can't reproduce the problem on debian i386. I put together a
>>>>> script
>>>>> that continually greps a apache child pid and kills it. After
>>>>> killing 200
>>>>> processes there is no change in the total number of apache
>>>>> processes, and
>>>>> nothing in the apache log other an entry for each process killed:
>>>>>
>>>>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died,
>>>>> restarting
>>>>> ...
>>>>>
>>>>> Regards,
>>>>> Jim
>>>>>
>>>>>
>>>>> Michel Jouvin wrote:
>>>>>
>>>>>> I don't know If really need to write a script, this is so simple.
>>>>>>
>>>>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>>>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>>>> start
>>>>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>>>> start
>>>>>> 1086396 1086105 grep http
>>>>>>
>>>>>>
>>>>>>
>>>>>>> From this output, you see that 1560163 is the child. Kill it
>>>>>>> with :
>>>>>>>
>>>>>>
>>>>>>
>>>>>> kill -KILL 1560163
>>>>>>
>>>>>> If you enter again 'ps -e|grep http', you'll see (I am
>>>>>> seeing...) the
>>>>>> number of httpd processes increasing until the max number
>>>>>> (determined by
>>>>>> MaxClient and ThreadPerChild). When this max number is reached
>>>>>> you get
>>>>>> the error message in main Apache error log.
>>>>>>
>>>>>> Michel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>>>>> <jp...@jgassociates.ca> wrote:
>>>>>>
>>>>>>
>>>>>>> Michel Jouvin wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Graham,
>>>>>>>>
>>>>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>>>>> MaxClient and suppressed child recycling
>>>>>>>> (MaxRequestPerChild=0) to
>>>>>>>> suppress restart of child as it seems to trig the problem with
>>>>>>>> mod_pyton. No effect.
>>>>>>>>
>>>>>>>> I also checked the load during all these tests. Almost no
>>>>>>>> request. So
>>>>>>>> the heavy load syndroma you described doesn't seem to apply in
>>>>>>>> this
>>>>>>>> case.
>>>>>>>>
>>>>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>>>>> configuration with mod_python loaded and without any url to
>>>>>>>> trig its
>>>>>>>> usages. And the problem was already the same. So it seems this
>>>>>>>> is not
>>>>>>>> related to mod_python usage (it happens even if you didn't
>>>>>>>> execute any
>>>>>>>> Python code) but rather to mod_python interaction with other
>>>>>>>> Apache
>>>>>>>> components.
>>>>>>>>
>>>>>>>> Michel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Michel,
>>>>>>>
>>>>>>> I'm not able to reproduce the behaviour on debian stable (i386)
>>>>>>> with
>>>>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>>>>
>>>>>>> Could you create a test script (bash or python) that will
>>>>>>> produce the
>>>>>>> error? That way I can know for sure that I'm testing in the
>>>>>>> same way.
>>>>>>>
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *************************************************************
>>>>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>>>>> * LAL / CNRS Tel : +33 1 64468932 *
>>>>>> * B.P. 34 Fax : +33 1 69079404 *
>>>>>> * 91898 Orsay Cedex *
>>>>>> * France *
>>>>>> *************************************************************
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> *************************************************************
>>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>>> * LAL / CNRS Tel : +33 1 64468932 *
>>>> * B.P. 34 Fax : +33 1 69079404 *
>>>> * 91898 Orsay Cedex *
>>>> * France *
>>>> *************************************************************
>>>>
>>>>
>>>
>>>
>>>
>>> *************************************************************
>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>> * LAL / CNRS Tel : +33 1 64468932 *
>>> * B.P. 34 Fax : +33 1 69079404 *
>>> * 91898 Orsay Cedex *
>>> * France *
>>> *************************************************************
>>>
>>>
>>
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
>
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
Graham,
No I am not using any PythonImport directive neither on the prod server,
nor on the test server. On the test server, the only mod_python related
directive is :
LoadModule python_module modules/mod_python.so
I'll try you suggestion about adding some logging messages in mod_python.c.
By the way, I just remember that I had one problem to build mod_python on
Tru64 with the native compiler (not tried with gcc) because of definition
conflict for macro _XOPEN_SOURCES defined by Phyton pyconfig.h. The problem
is that mod_python includes types.h without this macro defined to the value
used by Python and before including pyconfig.h (Python.h). My hack was
pretty dirty : undefine this macro in pyconfig.h to build mod_python
successfully. But may be it is responsible for this side effect
(unfortunatly this seems the only one...).
I'll try to find the time to check this in the coming days...
Michel
--On samedi 10 décembre 2005 15:00 +1100 Graham Dumpleton
<gr...@dscpl.com.au> wrote:
> Just to make sure, are you using PythonImport directive at all? Want to
> eliminate
> this as these get run regardless of whether a request against a
> mod_python
> handler is received. If the code associated with PythonImport took some
> time
> to run, that might be a contributor.
>
> Anyway, not sure what else to suggest. I would probably start adding
> extra
> logging calls in the mod_python.c file of mod_python so that one could
> see when
> the Apache child process init function for mod_python is entered and
> exited for
> each process ID. That way could see if that is returning quickly or
> taking some
> time.
>
> Graham
>
> On 10/12/2005, at 10:38 AM, Michel Jouvin wrote:
>
>> I am still fighting with my mod_python problem on Tru64. I have
>> been able to set up a test configuration with just standard Apache
>> modules and mod_python loaded (no php, no dav, no subversion...)
>> and without any url activating a mod_python handler.
>>
>> The problem remains the same. Just after starting Apache, with no
>> request received by this server, I 'kill -KILL' httpd slave and
>> this leads to the restart of other children that don't succeed to
>> initialize properly. Apache restarts as many children as it can
>> before giving up when it reaches MaxClients.
>>
>> Any idea on how to troubleshoot this and get any useful information
>> to debug this problem ?
>>
>> Thanks in advance.
>>
>> Michel
>>
>> --On jeudi 24 novembre 2005 23:43 +0100 Michel Jouvin
>> <jo...@lal.in2p3.fr> wrote:
>>
>>
>>> Jim,
>>>
>>> I am not totally surprised... I am afraid this is a platform specific
>>> issue as we are running mod_python on Tru64. Something like a 64 bits
>>> issue. Does it sound a reasonnable possibility ? How to progress in
>>> troubleshooting ?
>>>
>>> Michel
>>>
>>> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
>>> <jp...@jgassociates.ca> wrote:
>>>
>>>
>>>> Michel,
>>>>
>>>> I can't reproduce the problem on debian i386. I put together a
>>>> script
>>>> that continually greps a apache child pid and kills it. After
>>>> killing 200
>>>> processes there is no change in the total number of apache
>>>> processes, and
>>>> nothing in the apache log other an entry for each process killed:
>>>>
>>>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died,
>>>> restarting
>>>> ...
>>>>
>>>> Regards,
>>>> Jim
>>>>
>>>>
>>>> Michel Jouvin wrote:
>>>>
>>>>> I don't know If really need to write a script, this is so simple.
>>>>>
>>>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>>> start
>>>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>>> start
>>>>> 1086396 1086105 grep http
>>>>>
>>>>>
>>>>>
>>>>>> From this output, you see that 1560163 is the child. Kill it
>>>>>> with :
>>>>>>
>>>>>
>>>>>
>>>>> kill -KILL 1560163
>>>>>
>>>>> If you enter again 'ps -e|grep http', you'll see (I am
>>>>> seeing...) the
>>>>> number of httpd processes increasing until the max number
>>>>> (determined by
>>>>> MaxClient and ThreadPerChild). When this max number is reached
>>>>> you get
>>>>> the error message in main Apache error log.
>>>>>
>>>>> Michel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>>>> <jp...@jgassociates.ca> wrote:
>>>>>
>>>>>
>>>>>> Michel Jouvin wrote:
>>>>>>
>>>>>>
>>>>>>> Graham,
>>>>>>>
>>>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>>>> MaxClient and suppressed child recycling
>>>>>>> (MaxRequestPerChild=0) to
>>>>>>> suppress restart of child as it seems to trig the problem with
>>>>>>> mod_pyton. No effect.
>>>>>>>
>>>>>>> I also checked the load during all these tests. Almost no
>>>>>>> request. So
>>>>>>> the heavy load syndroma you described doesn't seem to apply in
>>>>>>> this
>>>>>>> case.
>>>>>>>
>>>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>>>> configuration with mod_python loaded and without any url to
>>>>>>> trig its
>>>>>>> usages. And the problem was already the same. So it seems this
>>>>>>> is not
>>>>>>> related to mod_python usage (it happens even if you didn't
>>>>>>> execute any
>>>>>>> Python code) but rather to mod_python interaction with other
>>>>>>> Apache
>>>>>>> components.
>>>>>>>
>>>>>>> Michel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Michel,
>>>>>>
>>>>>> I'm not able to reproduce the behaviour on debian stable (i386)
>>>>>> with
>>>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>>>
>>>>>> Could you create a test script (bash or python) that will
>>>>>> produce the
>>>>>> error? That way I can know for sure that I'm testing in the
>>>>>> same way.
>>>>>>
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *************************************************************
>>>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>>>> * LAL / CNRS Tel : +33 1 64468932 *
>>>>> * B.P. 34 Fax : +33 1 69079404 *
>>>>> * 91898 Orsay Cedex *
>>>>> * France *
>>>>> *************************************************************
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> *************************************************************
>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>> * LAL / CNRS Tel : +33 1 64468932 *
>>> * B.P. 34 Fax : +33 1 69079404 *
>>> * 91898 Orsay Cedex *
>>> * France *
>>> *************************************************************
>>>
>>>
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
>>
>>
>
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
Just to make sure, are you using PythonImport directive at all? Want
to eliminate
this as these get run regardless of whether a request against a
mod_python
handler is received. If the code associated with PythonImport took
some time
to run, that might be a contributor.
Anyway, not sure what else to suggest. I would probably start adding
extra
logging calls in the mod_python.c file of mod_python so that one
could see when
the Apache child process init function for mod_python is entered and
exited for
each process ID. That way could see if that is returning quickly or
taking some
time.
Graham
On 10/12/2005, at 10:38 AM, Michel Jouvin wrote:
> I am still fighting with my mod_python problem on Tru64. I have
> been able to set up a test configuration with just standard Apache
> modules and mod_python loaded (no php, no dav, no subversion...)
> and without any url activating a mod_python handler.
>
> The problem remains the same. Just after starting Apache, with no
> request received by this server, I 'kill -KILL' httpd slave and
> this leads to the restart of other children that don't succeed to
> initialize properly. Apache restarts as many children as it can
> before giving up when it reaches MaxClients.
>
> Any idea on how to troubleshoot this and get any useful information
> to debug this problem ?
>
> Thanks in advance.
>
> Michel
>
> --On jeudi 24 novembre 2005 23:43 +0100 Michel Jouvin
> <jo...@lal.in2p3.fr> wrote:
>
>
>> Jim,
>>
>> I am not totally surprised... I am afraid this is a platform specific
>> issue as we are running mod_python on Tru64. Something like a 64 bits
>> issue. Does it sound a reasonnable possibility ? How to progress in
>> troubleshooting ?
>>
>> Michel
>>
>> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
>> <jp...@jgassociates.ca> wrote:
>>
>>
>>> Michel,
>>>
>>> I can't reproduce the problem on debian i386. I put together a
>>> script
>>> that continually greps a apache child pid and kills it. After
>>> killing 200
>>> processes there is no change in the total number of apache
>>> processes, and
>>> nothing in the apache log other an entry for each process killed:
>>>
>>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died,
>>> restarting
>>> ...
>>>
>>> Regards,
>>> Jim
>>>
>>>
>>> Michel Jouvin wrote:
>>>
>>>> I don't know If really need to write a script, this is so simple.
>>>>
>>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>> start
>>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k
>>>> start
>>>> 1086396 1086105 grep http
>>>>
>>>>
>>>>
>>>>> From this output, you see that 1560163 is the child. Kill it
>>>>> with :
>>>>>
>>>>
>>>>
>>>> kill -KILL 1560163
>>>>
>>>> If you enter again 'ps -e|grep http', you'll see (I am
>>>> seeing...) the
>>>> number of httpd processes increasing until the max number
>>>> (determined by
>>>> MaxClient and ThreadPerChild). When this max number is reached
>>>> you get
>>>> the error message in main Apache error log.
>>>>
>>>> Michel
>>>>
>>>>
>>>>
>>>>
>>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>>> <jp...@jgassociates.ca> wrote:
>>>>
>>>>
>>>>> Michel Jouvin wrote:
>>>>>
>>>>>
>>>>>> Graham,
>>>>>>
>>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>>> MaxClient and suppressed child recycling
>>>>>> (MaxRequestPerChild=0) to
>>>>>> suppress restart of child as it seems to trig the problem with
>>>>>> mod_pyton. No effect.
>>>>>>
>>>>>> I also checked the load during all these tests. Almost no
>>>>>> request. So
>>>>>> the heavy load syndroma you described doesn't seem to apply in
>>>>>> this
>>>>>> case.
>>>>>>
>>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>>> configuration with mod_python loaded and without any url to
>>>>>> trig its
>>>>>> usages. And the problem was already the same. So it seems this
>>>>>> is not
>>>>>> related to mod_python usage (it happens even if you didn't
>>>>>> execute any
>>>>>> Python code) but rather to mod_python interaction with other
>>>>>> Apache
>>>>>> components.
>>>>>>
>>>>>> Michel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Michel,
>>>>>
>>>>> I'm not able to reproduce the behaviour on debian stable (i386)
>>>>> with
>>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>>
>>>>> Could you create a test script (bash or python) that will
>>>>> produce the
>>>>> error? That way I can know for sure that I'm testing in the
>>>>> same way.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> *************************************************************
>>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>>> * LAL / CNRS Tel : +33 1 64468932 *
>>>> * B.P. 34 Fax : +33 1 69079404 *
>>>> * 91898 Orsay Cedex *
>>>> * France *
>>>> *************************************************************
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
>>
>>
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
>
>
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
I am still fighting with my mod_python problem on Tru64. I have been able
to set up a test configuration with just standard Apache modules and
mod_python loaded (no php, no dav, no subversion...) and without any url
activating a mod_python handler.
The problem remains the same. Just after starting Apache, with no request
received by this server, I 'kill -KILL' httpd slave and this leads to the
restart of other children that don't succeed to initialize properly. Apache
restarts as many children as it can before giving up when it reaches
MaxClients.
Any idea on how to troubleshoot this and get any useful information to
debug this problem ?
Thanks in advance.
Michel
--On jeudi 24 novembre 2005 23:43 +0100 Michel Jouvin <jo...@lal.in2p3.fr>
wrote:
> Jim,
>
> I am not totally surprised... I am afraid this is a platform specific
> issue as we are running mod_python on Tru64. Something like a 64 bits
> issue. Does it sound a reasonnable possibility ? How to progress in
> troubleshooting ?
>
> Michel
>
> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
> <jp...@jgassociates.ca> wrote:
>
>> Michel,
>>
>> I can't reproduce the problem on debian i386. I put together a script
>> that continually greps a apache child pid and kills it. After killing 200
>> processes there is no change in the total number of apache processes, and
>> nothing in the apache log other an entry for each process killed:
>>
>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting
>> ...
>>
>> Regards,
>> Jim
>>
>>
>> Michel Jouvin wrote:
>>> I don't know If really need to write a script, this is so simple.
>>>
>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>> 1086396 1086105 grep http
>>>
>>>
>>>> From this output, you see that 1560163 is the child. Kill it with :
>>>
>>>
>>> kill -KILL 1560163
>>>
>>> If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
>>> number of httpd processes increasing until the max number (determined by
>>> MaxClient and ThreadPerChild). When this max number is reached you get
>>> the error message in main Apache error log.
>>>
>>> Michel
>>>
>>>
>>>
>>>
>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>> <jp...@jgassociates.ca> wrote:
>>>
>>>> Michel Jouvin wrote:
>>>>
>>>>> Graham,
>>>>>
>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>> MaxClient and suppressed child recycling (MaxRequestPerChild=0) to
>>>>> suppress restart of child as it seems to trig the problem with
>>>>> mod_pyton. No effect.
>>>>>
>>>>> I also checked the load during all these tests. Almost no request. So
>>>>> the heavy load syndroma you described doesn't seem to apply in this
>>>>> case.
>>>>>
>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>> configuration with mod_python loaded and without any url to trig its
>>>>> usages. And the problem was already the same. So it seems this is not
>>>>> related to mod_python usage (it happens even if you didn't execute any
>>>>> Python code) but rather to mod_python interaction with other Apache
>>>>> components.
>>>>>
>>>>> Michel
>>>>
>>>>
>>>>
>>>> Michel,
>>>>
>>>> I'm not able to reproduce the behaviour on debian stable (i386) with
>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>
>>>> Could you create a test script (bash or python) that will produce the
>>>> error? That way I can know for sure that I'm testing in the same way.
>>>>
>>>> Jim
>>>>
>>>
>>>
>>>
>>> *************************************************************
>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>> * LAL / CNRS Tel : +33 1 64468932 *
>>> * B.P. 34 Fax : +33 1 69079404 *
>>> * 91898 Orsay Cedex *
>>> * France *
>>> *************************************************************
>>>
>>>
>>>
>>
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
>
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Posted by Nick <ni...@dd.revealed.net>.
for myself, I have not had problems on ubuntu 5.10 amd64.
Nick
Jim Gallacher wrote:
> Michel Jouvin wrote:
>
>> Jim,
>>
>> I am not totally surprised... I am afraid this is a platform specific
>> issue as we are running mod_python on Tru64. Something like a 64 bits
>> issue. Does it sound a reasonnable possibility ?
>
>
> I have no idea what may be going on, but that seems as likely as
> anything else.
>
>> How to progress in troubleshooting ?
>
>
> Again, no clue. :(. Hopefully some of the bigger brains that hang out
> around here will chime in. I know Indrek Järve tested 3.2.2b on SuSE
> Linux 9.2 (x86-64). Perhaps he or someone else with a 64-bit platform
> could try and reproduce the problem. That would tell us if it's 64-bit
> related or Tru64 related.
>
> I've attached my test script if anyone wants to mess with it. I'm sure I
> don't need to tell you to *not* run it on a production machine. ;)
> You'll likely want to change the PAUSE variable to something less than
> 30 seconds, which is the time between the kill calls. I was testing
> using qemu, and it needs lots of time for things to happen.
>
> usage: ./killchildren <# number of loops>
>
> Jim
>
> > Michel
>
>>
>> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
>> <jp...@jgassociates.ca> wrote:
>>
>>> Michel,
>>>
>>> I can't reproduce the problem on debian i386. I put together a script
>>> that continually greps a apache child pid and kills it. After killing
>>> 200
>>> processes there is no change in the total number of apache processes,
>>> and
>>> nothing in the apache log other an entry for each process killed:
>>>
>>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting
>>> ...
>>>
>>> Regards,
>>> Jim
>>>
>>>
>>> Michel Jouvin wrote:
>>>
>>>> I don't know If really need to write a script, this is so simple.
>>>>
>>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>>> 1086396 1086105 grep http
>>>>
>>>>
>>>>> From this output, you see that 1560163 is the child. Kill it with :
>>>>
>>>>
>>>>
>>>>
>>>> kill -KILL 1560163
>>>>
>>>> If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
>>>> number of httpd processes increasing until the max number
>>>> (determined by
>>>> MaxClient and ThreadPerChild). When this max number is reached you get
>>>> the error message in main Apache error log.
>>>>
>>>> Michel
>>>>
>>>>
>>>>
>>>>
>>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>>> <jp...@jgassociates.ca> wrote:
>>>>
>>>>> Michel Jouvin wrote:
>>>>>
>>>>>> Graham,
>>>>>>
>>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>>> MaxClient and suppressed child recycling (MaxRequestPerChild=0) to
>>>>>> suppress restart of child as it seems to trig the problem with
>>>>>> mod_pyton. No effect.
>>>>>>
>>>>>> I also checked the load during all these tests. Almost no request. So
>>>>>> the heavy load syndroma you described doesn't seem to apply in this
>>>>>> case.
>>>>>>
>>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>>> configuration with mod_python loaded and without any url to trig its
>>>>>> usages. And the problem was already the same. So it seems this is not
>>>>>> related to mod_python usage (it happens even if you didn't execute
>>>>>> any
>>>>>> Python code) but rather to mod_python interaction with other Apache
>>>>>> components.
>>>>>>
>>>>>> Michel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Michel,
>>>>>
>>>>> I'm not able to reproduce the behaviour on debian stable (i386) with
>>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>>
>>>>> Could you create a test script (bash or python) that will produce the
>>>>> error? That way I can know for sure that I'm testing in the same way.
>>>>>
>>>>> Jim
>>>>>
>>>>
>>>>
>>>>
>>>> *************************************************************
>>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>>> * LAL / CNRS Tel : +33 1 64468932 *
>>>> * B.P. 34 Fax : +33 1 69079404 *
>>>> * 91898 Orsay Cedex *
>>>> * France *
>>>> *************************************************************
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
>>
>>
>>
>
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Michel Jouvin wrote:
> Jim,
>
> I am not totally surprised... I am afraid this is a platform specific
> issue as we are running mod_python on Tru64. Something like a 64 bits
> issue. Does it sound a reasonnable possibility ?
I have no idea what may be going on, but that seems as likely as
anything else.
> How to progress in
> troubleshooting ?
Again, no clue. :(. Hopefully some of the bigger brains that hang out
around here will chime in. I know Indrek Järve tested 3.2.2b on SuSE
Linux 9.2 (x86-64). Perhaps he or someone else with a 64-bit platform
could try and reproduce the problem. That would tell us if it's 64-bit
related or Tru64 related.
I've attached my test script if anyone wants to mess with it. I'm sure I
don't need to tell you to *not* run it on a production machine. ;)
You'll likely want to change the PAUSE variable to something less than
30 seconds, which is the time between the kill calls. I was testing
using qemu, and it needs lots of time for things to happen.
usage: ./killchildren <# number of loops>
Jim
> Michel
>
> --On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
> <jp...@jgassociates.ca> wrote:
>
>> Michel,
>>
>> I can't reproduce the problem on debian i386. I put together a script
>> that continually greps a apache child pid and kills it. After killing 200
>> processes there is no change in the total number of apache processes, and
>> nothing in the apache log other an entry for each process killed:
>>
>> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting
>> ...
>>
>> Regards,
>> Jim
>>
>>
>> Michel Jouvin wrote:
>>
>>> I don't know If really need to write a script, this is so simple.
>>>
>>> asa/root % ps -e -opid,ppid,cmd | grep http
>>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>>> 1086396 1086105 grep http
>>>
>>>
>>>> From this output, you see that 1560163 is the child. Kill it with :
>>>
>>>
>>>
>>> kill -KILL 1560163
>>>
>>> If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
>>> number of httpd processes increasing until the max number (determined by
>>> MaxClient and ThreadPerChild). When this max number is reached you get
>>> the error message in main Apache error log.
>>>
>>> Michel
>>>
>>>
>>>
>>>
>>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>>> <jp...@jgassociates.ca> wrote:
>>>
>>>> Michel Jouvin wrote:
>>>>
>>>>> Graham,
>>>>>
>>>>> I played a little bit with worker MPM parameters. In particular I
>>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>>> MaxClient and suppressed child recycling (MaxRequestPerChild=0) to
>>>>> suppress restart of child as it seems to trig the problem with
>>>>> mod_pyton. No effect.
>>>>>
>>>>> I also checked the load during all these tests. Almost no request. So
>>>>> the heavy load syndroma you described doesn't seem to apply in this
>>>>> case.
>>>>>
>>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>>> configuration with mod_python loaded and without any url to trig its
>>>>> usages. And the problem was already the same. So it seems this is not
>>>>> related to mod_python usage (it happens even if you didn't execute any
>>>>> Python code) but rather to mod_python interaction with other Apache
>>>>> components.
>>>>>
>>>>> Michel
>>>>
>>>>
>>>>
>>>>
>>>> Michel,
>>>>
>>>> I'm not able to reproduce the behaviour on debian stable (i386) with
>>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>>
>>>> Could you create a test script (bash or python) that will produce the
>>>> error? That way I can know for sure that I'm testing in the same way.
>>>>
>>>> Jim
>>>>
>>>
>>>
>>>
>>> *************************************************************
>>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>>> * LAL / CNRS Tel : +33 1 64468932 *
>>> * B.P. 34 Fax : +33 1 69079404 *
>>> * 91898 Orsay Cedex *
>>> * France *
>>> *************************************************************
>>>
>>>
>>>
>>
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
>
>
>
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
Jim,
I am not totally surprised... I am afraid this is a platform specific issue
as we are running mod_python on Tru64. Something like a 64 bits issue. Does
it sound a reasonnable possibility ? How to progress in troubleshooting ?
Michel
--On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher <jp...@jgassociates.ca>
wrote:
> Michel,
>
> I can't reproduce the problem on debian i386. I put together a script
> that continually greps a apache child pid and kills it. After killing 200
> processes there is no change in the total number of apache processes, and
> nothing in the apache log other an entry for each process killed:
>
> [Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting
> ...
>
> Regards,
> Jim
>
>
> Michel Jouvin wrote:
>> I don't know If really need to write a script, this is so simple.
>>
>> asa/root % ps -e -opid,ppid,cmd | grep http
>> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
>> 1086396 1086105 grep http
>>
>>
>>> From this output, you see that 1560163 is the child. Kill it with :
>>
>>
>> kill -KILL 1560163
>>
>> If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
>> number of httpd processes increasing until the max number (determined by
>> MaxClient and ThreadPerChild). When this max number is reached you get
>> the error message in main Apache error log.
>>
>> Michel
>>
>>
>>
>>
>> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
>> <jp...@jgassociates.ca> wrote:
>>
>>> Michel Jouvin wrote:
>>>
>>>> Graham,
>>>>
>>>> I played a little bit with worker MPM parameters. In particular I
>>>> tested your suggestion to increase to 2 StartServers. This has no
>>>> effect on the problem. I also tried to raise MaxSpareThread to
>>>> MaxClient and suppressed child recycling (MaxRequestPerChild=0) to
>>>> suppress restart of child as it seems to trig the problem with
>>>> mod_pyton. No effect.
>>>>
>>>> I also checked the load during all these tests. Almost no request. So
>>>> the heavy load syndroma you described doesn't seem to apply in this
>>>> case.
>>>>
>>>> Again, one month ago I tested during 2 or 3 days an Apache
>>>> configuration with mod_python loaded and without any url to trig its
>>>> usages. And the problem was already the same. So it seems this is not
>>>> related to mod_python usage (it happens even if you didn't execute any
>>>> Python code) but rather to mod_python interaction with other Apache
>>>> components.
>>>>
>>>> Michel
>>>
>>>
>>>
>>> Michel,
>>>
>>> I'm not able to reproduce the behaviour on debian stable (i386) with
>>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>>
>>> Could you create a test script (bash or python) that will produce the
>>> error? That way I can know for sure that I'm testing in the same way.
>>>
>>> Jim
>>>
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
>>
>>
>>
>
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Michel,
I can't reproduce the problem on debian i386. I put together a script
that continually greps a apache child pid and kills it. After killing
200 processes there is no change in the total number of apache
processes, and nothing in the apache log other an entry for each process
killed:
[Thu Nov 24 17:03:44 2005] [error] cgid daemon process died, restarting
...
Regards,
Jim
Michel Jouvin wrote:
> I don't know If really need to write a script, this is so simple.
>
> asa/root % ps -e -opid,ppid,cmd | grep http
> 1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
> 1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
> 1086396 1086105 grep http
>
>
>> From this output, you see that 1560163 is the child. Kill it with :
>
>
> kill -KILL 1560163
>
> If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
> number of httpd processes increasing until the max number (determined by
> MaxClient and ThreadPerChild). When this max number is reached you get
> the error message in main Apache error log.
>
> Michel
>
>
>
>
> --On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
> <jp...@jgassociates.ca> wrote:
>
>> Michel Jouvin wrote:
>>
>>> Graham,
>>>
>>> I played a little bit with worker MPM parameters. In particular I tested
>>> your suggestion to increase to 2 StartServers. This has no effect on the
>>> problem. I also tried to raise MaxSpareThread to MaxClient and
>>> suppressed child recycling (MaxRequestPerChild=0) to suppress restart of
>>> child as it seems to trig the problem with mod_pyton. No effect.
>>>
>>> I also checked the load during all these tests. Almost no request. So
>>> the heavy load syndroma you described doesn't seem to apply in this
>>> case.
>>>
>>> Again, one month ago I tested during 2 or 3 days an Apache configuration
>>> with mod_python loaded and without any url to trig its usages. And the
>>> problem was already the same. So it seems this is not related to
>>> mod_python usage (it happens even if you didn't execute any Python code)
>>> but rather to mod_python interaction with other Apache components.
>>>
>>> Michel
>>
>>
>>
>> Michel,
>>
>> I'm not able to reproduce the behaviour on debian stable (i386) with
>> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>>
>> Could you create a test script (bash or python) that will produce the
>> error? That way I can know for sure that I'm testing in the same way.
>>
>> Jim
>>
>
>
>
> *************************************************************
> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
> * LAL / CNRS Tel : +33 1 64468932 *
> * B.P. 34 Fax : +33 1 69079404 *
> * 91898 Orsay Cedex *
> * France *
> *************************************************************
>
>
>
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
I don't know If really need to write a script, this is so simple.
asa/root % ps -e -opid,ppid,cmd | grep http
1560138 1048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start
1560163 1560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start
1086396 1086105 grep http
>From this output, you see that 1560163 is the child. Kill it with :
kill -KILL 1560163
If you enter again 'ps -e|grep http', you'll see (I am seeing...) the
number of httpd processes increasing until the max number (determined by
MaxClient and ThreadPerChild). When this max number is reached you get the
error message in main Apache error log.
Michel
--On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
<jp...@jgassociates.ca> wrote:
> Michel Jouvin wrote:
>> Graham,
>>
>> I played a little bit with worker MPM parameters. In particular I tested
>> your suggestion to increase to 2 StartServers. This has no effect on the
>> problem. I also tried to raise MaxSpareThread to MaxClient and
>> suppressed child recycling (MaxRequestPerChild=0) to suppress restart of
>> child as it seems to trig the problem with mod_pyton. No effect.
>>
>> I also checked the load during all these tests. Almost no request. So
>> the heavy load syndroma you described doesn't seem to apply in this case.
>>
>> Again, one month ago I tested during 2 or 3 days an Apache configuration
>> with mod_python loaded and without any url to trig its usages. And the
>> problem was already the same. So it seems this is not related to
>> mod_python usage (it happens even if you didn't execute any Python code)
>> but rather to mod_python interaction with other Apache components.
>>
>> Michel
>
>
> Michel,
>
> I'm not able to reproduce the behaviour on debian stable (i386) with
> apache 2.0.54, but I'm not sure if I'm testing this correctly.
>
> Could you create a test script (bash or python) that will produce the
> error? That way I can know for sure that I'm testing in the same way.
>
> Jim
>
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Michel Jouvin wrote:
> Graham,
>
> I played a little bit with worker MPM parameters. In particular I tested
> your suggestion to increase to 2 StartServers. This has no effect on the
> problem. I also tried to raise MaxSpareThread to MaxClient and
> suppressed child recycling (MaxRequestPerChild=0) to suppress restart of
> child as it seems to trig the problem with mod_pyton. No effect.
>
> I also checked the load during all these tests. Almost no request. So
> the heavy load syndroma you described doesn't seem to apply in this case.
>
> Again, one month ago I tested during 2 or 3 days an Apache configuration
> with mod_python loaded and without any url to trig its usages. And the
> problem was already the same. So it seems this is not related to
> mod_python usage (it happens even if you didn't execute any Python code)
> but rather to mod_python interaction with other Apache components.
>
> Michel
Michel,
I'm not able to reproduce the behaviour on debian stable (i386) with
apache 2.0.54, but I'm not sure if I'm testing this correctly.
Could you create a test script (bash or python) that will produce the
error? That way I can know for sure that I'm testing in the same way.
Jim
Re: 3.2b5 : mod_python doesn't handle properly signals
likeKILL,SEGV...
Posted by Michel Jouvin <jo...@lal.in2p3.fr>.
Graham,
I played a little bit with worker MPM parameters. In particular I tested
your suggestion to increase to 2 StartServers. This has no effect on the
problem. I also tried to raise MaxSpareThread to MaxClient and suppressed
child recycling (MaxRequestPerChild=0) to suppress restart of child as it
seems to trig the problem with mod_pyton. No effect.
I also checked the load during all these tests. Almost no request. So the
heavy load syndroma you described doesn't seem to apply in this case.
Again, one month ago I tested during 2 or 3 days an Apache configuration
with mod_python loaded and without any url to trig its usages. And the
problem was already the same. So it seems this is not related to mod_python
usage (it happens even if you didn't execute any Python code) but rather to
mod_python interaction with other Apache components.
Michel
--On mardi 22 novembre 2005 00:37 -0500 Graham Dumpleton
<gr...@dscpl.com.au> wrote:
> Sorry, a couple more questions.
>
> When you kill the child process, is Apache under load, ie., receiving
> lots of requests or in an idle state with no requests being received?
> Also, do you get the same results if you set "StartServers" to 2 and
> kill off only one child process?
>
> If you only have one child process and kill it, and lots of requests are
> coming in, am wandering if Apache gets confused, thinking that the newly
> spawned child process isn't ready and thus it decides to start a new
> one. If this were happening but you have "StartServers" at 2 to begin
> with such that you always have at least 1 child process even when you
> kill off one of the originals, all those requests coming in would get
> bumped off to the remaining child process and Apache may decide
> not to create additional child processes.
>
> Hope you can see what I am thinking.
>
> Graham
>
>
> Michel Jouvin wrote ..
>> Graham,
>>
>> Sorry for the ambiguity. With worker MPM, the max number of process is
>> the
>> max number of threads divided by the number of thread per process. My
>> config is :
>>
>> # worker MPM
>> # StartServers: initial number of server processes to start
>> # MaxClients: maximum number of simultaneous client connections
>> # MinSpareThreads: minimum number of worker threads which are kept spare
>> # MaxSpareThreads: maximum number of worker threads which are kept spare
>> # ThreadsPerChild: constant number of worker threads in each server
>> # process
>>
>> <IfModule worker.c>
>> MaxClients 245
>> StartServers 1
>> MinSpareThreads 5
>> MaxSpareThreads 10
>> ThreadsPerChild 35
>> </IfModule>
>>
>> In our case that means that one process can handle 35 requessts and
>> normally we have only one httpd slave running.
>>
>> After mod_python receives a signal like KILL or SEGV (in fact anything
>> except TERM or HUP if I am right, you can test with kill command), I
>> have 8 httpd slave processes and the following message in main Apache
>> error log
>> file :
>>
>> [error] server reached MaxClients setting, consider raising the
>> MaxClients setting
>>
>> The only solution is to stop and start (not graceful restart) Apache.
>>
>> Cheers,
>>
>> Michel
>>
>> --On lundi 21 novembre 2005 19:28 -0500 Graham Dumpleton
>> <gr...@dscpl.com.au> wrote:
>>
>> > Michel Jouvin wrote ..
>> >> Hi,
>> >>
>> >> I recently installed mod_python 3.2b5 on Apache 2.0.54. I am running
>> with
>> >> problems if httpd slave process segfaults or is killed. In this case,
>> >> master process restart the max number of processes/threads. We are
>> >> running Apache with the MPM worker (on Tru64 platform).
>> >>
>> >> This behaviour appears only if mod_python is loaded into Apache. this
>> >> doesn't seem to be related to mod_python usage : this can happen if
>> you
>> >> load mod_python even if no URL is configured to use it. You can easily
>> >> reproduce the problem by doing 'kill -KILL' of an Apache slave
>> >> process.
>> >>
>> >> Is it a known issue ? Are they any workaround ?
>> >
>> > What settings do you have in Apache config for:
>> >
>> > <IfModule worker.c>
>> ># StartServers 2
>> > StartServers 1
>> > MaxClients 150
>> > MinSpareThreads 25
>> > MaxSpareThreads 75
>> > ThreadsPerChild 25
>> > MaxRequestsPerChild 0
>> > </IfModule>
>> >
>> > Can you then relate your problem to your configuration with actual
>> > numbers?
>> >
>> > Note that with "worker" configuration, there isn't generally a
>> > MaxSpareServers or MinSpareServers setting as I understand, that is for
>> > prefork only.
>> >
>> > <IfModule prefork.c>
>> > StartServers 5
>> > MinSpareServers 5
>> > MaxSpareServers 10
>> > MaxClients 150
>> > MaxRequestsPerChild 0
>> > </IfModule>
>> >
>> > So not sure when you say that it creates maximum number of processes
>> > what you are exactly talking about. I might expect it to create number
>> > of processes as specified by StartServers.
>> >
>> > Thus, can you please clarify.
>> >
>> > Graham
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : jouvin@lal.in2p3.fr *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
*************************************************************
* Michel Jouvin Email : jouvin@lal.in2p3.fr *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************