[mod_python] OS X / Apache 2 / mod_python bug

Jamie Kirkpatrick jkp at kirkconsulting.co.uk
Mon Mar 14 04:07:55 EST 2005


On 13 Mar 2005, at 21:06, Graham Dumpleton wrote:

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?


Yep.



Does every request against the server result in 500 being returned,

or only requests which fall under the control of mod_python?




Only those that fall under mod_python.  Other pages are fine.



Does running "apachectl configtest" yield any sort of error or warning

message?


None.



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.


None.  The same configuration works fine using start / stop, there is  
nothing in the error nor access log.




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.


It's all configured from the main config file.



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.




I can post but its rather long - I am pretty darn confident that there  
is nothing wrong with the config tho.  I havent changed barely anything  
from the stock install, in-fact, I can reproduce the error by leaving  
everything as is from when the install is performed and only adding a  
python handler to the default htdocs directory.  The only thing I have  
consistently changed is the port the server is listening on to port  
8080.  I have tested with the minimum of changes: added a handler and  
dropped in a small test script.



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?


I used the hello.py example from the site and consistently got the same  
results.  This was how I finally pinned it down to mod_python.  See the  
last answer for further details.



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?


See answer above.  The other app uses all sorts, but this is  
fairly irrelevant since i can reproduce the error on a test script.  PS  
- Im not a python programmer at all so I am fairly bad at being able to  
track things down within python itself.



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?


In all cases it shows as being cleanly loaded.



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 patched this existing Apple Makefile  
(/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/config/Makefile) with



:98



LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS)  
-bundle -undefined dynamic_lookup

BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS)  
-bundle -undefined dynamic_lookup



and I patched any other 3.3.x Makefiles too as per older emails.




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?


Nope.

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.


I did not try any of these options - perhaps I'll look them up but I do  
feel it should build without stuff like that.  I could be wrong tho!



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.


sure...anything I can do to help.  I havent included the config file  
now as its so long.  If you feel its gonna help I'll do so in the next  
mail.  Also, sorry for the shortness of some of my responses - It's  
early here!  I wanted to get something back to you so you wouild know  
something more, I hope what I have written will give you a better  
picture.  I look forward to helping to iron this one out.



Graham




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6912 bytes
Desc: not available
Url : http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20050314/bfb5ce0c/attachment.bin


More information about the Mod_python mailing list