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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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 : [EMAIL PROTECTED] *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
*************************************************************
* Michel Jouvin Email : [EMAIL PROTECTED] *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
*************************************************************
* Michel Jouvin Email : [EMAIL PROTECTED] *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
*************************************************************
* Michel Jouvin Email : [EMAIL PROTECTED] *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
