|
Graham Dumpleton
grahamd at dscpl.com.au
Sun Mar 13 16:06:13 EST 2005
Just want to confirm a few things. Please try and answer all the questions even if you think the answer should be obvious. Something in your response might indicate something to someone. On Sunday, March 13, 2005, at 10:39 PM, Jamie Kirkpatrick wrote: > The bug I have discovered basically boils down to a tiny thing that is > not an easy thing to discover. If you use `apachectl restart` to > control the execution of Apache with mod_python installed on OS X > (server at least, I didnt try the client version but I imagine it will > be the same), you will find mod_python ceases to function, producing a > 500 error from apache. A 500 error is something that would be returned for a request from a client. This therefore suggests that the restart appears to work but then upon receiving a request it delivers up a 500 error to the client. Is this what you mean? Does every request against the server result in 500 being returned, or only requests which fall under the control of mod_python? Does running "apachectl configtest" yield any sort of error or warning message? If there is some sort of configuration error in the main Apache config file, this would usually be displayed on restart/start but can also be seen by running configtest. If a configuration error appears in a .htaccess file however, you only know because the client will receive a 500 error when making a request against a directory controlled by that .htaccess file. From what I have seen, nothing normally gets logged in this case. That said, have you setup use of Apache in the main configuration file or in a .htaccess file? Can you post what configuration you are using so we can see if it is pretty normal or something strange? Post it if you can. Do you get these 500 errors if the only mod_python application configured is a really basic "mptest" type test handler, or does it only happen when you go to set it up for this more complicated application? What parts of mod_python does this more complicated application use? does it use mod_python.psp, or mod_python.publisher? Does it make use of cookies or session support in mod_python? Apart from configuration problems, 500 errors can be raised from within your code itself, so knowing whether your code is dependent on certain packages may be important. Also knowing if it uses sessions may also be useful, as it may be some sort of corruption in the session database. In both cases when you use restart/start, does the Apache log file clearly show mod_python being loaded and initialised? > As I say , this is not an easy bug to discover, since you never expect > there to be a difference in the way a module behaves due to such an > obscure thing. I can confirm that this happens on OS X Server > 10.3.6-8 with various different builds of apache2. I used the stock > build, a custom built version (from the latest sources) and one from > dports with the same results. I also tried different versions of > python (The stock 2.3 Framework, 2.4 built as a framework, 2.4 normal, > 2.3 normal....) as I had read on these lists that there are some > oddities in this area on OS X. Same results. Just as I was > beginning to give up completely I worked out what was going on. :p When you used stock Python 2.3 supplied by Apple, did you have the patches applied which were mentioned in previous email? Without this patch, the Apache child process would have crashed the first time it received a request for mod_python. I don't recollect whether the client would have seen a 500 error or not, but that the process crashed is evident in the Apache log file. > I really hope however that my findings can be investigated further so > that the bug can be resolved and a fix can be rolled into the trunk. > > I am happy to do any further testing if a patch is added by anyone. I > would like to try myself, but I just don't have the time to get > further into this stuff. Answering the above questions would be a good first step to knowing a bit more about your circumstances. A few other things that may prove useful are listed below. Are you using Apache in "prefork" mode? Did you ever compile it up in "worker" mode with threading to see if it made a difference? If using "worker" did you restrict it to one process with many threads? Doing this would cause session database to go from being disked based to memory based. Did you try removing the session database from /tmp. Anyway, if you are prepared to go to a bit of effort to answer each question we can see if we can sort this out. Graham
|