Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
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 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
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 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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 / CNRSTel : +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...
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 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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 / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* * * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +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...
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 [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 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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 / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* * * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* * killchildren.sh Description: application/shellscript
Re: 3.2b5 : mod_python doesn't handle properly signals likeKILL,SEGV...
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 [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 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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 / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* * * * Michel Jouvin Email : [EMAIL PROTECTED] * * LAL / CNRSTel : +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...
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...
I don't know If really need to write a script, this is so simple. asa/root % ps -e -opid,ppid,cmd | grep http 15601381048577 /www/Web/servers/apache/2.0.54/bin/httpd -k start 15601631560138 /www/Web/servers/apache/2.0.54/bin/httpd -k start 10863961086105 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 / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
