2009/11/17 Alex.yu <
vit...@gmail.com>:
Do each of the following in turn:
1. Add:
WSGIApplicationGroup %{GLOBAL}
to configuration just under WSGIScriptAlias.
This will force main Python interpreter within process to be used.
This can be needed for C extension modules for Python which are not
coded correctly so as to run in secondary sub interpreters. SWIG
generated extensions are known to have issues in this respect,
although normally it causes a deadlock with request not returning.
Restart and retest to see if it makes a difference.
2. Delegate your application to run in daemon mode rather than
embedded mode, this will make it easier to determine what is going
wrong and also make it easier to detect whether problem is caused by
process crashing.
To do this add:
WSGIDaemonProcess mysite display-name=%{GROUP}
WSGIProcessGroup mysite
just under WSGIScriptAlias.
Keep the WSGIApplicationGroup directive from above.
Also ensure that Apache LogLevel is set to 'info' rather than 'warn'.
This will result in mod_wsgi outputing more logging about what it is
doing and so easier to see if processes restarting.
Restart and retest to see if it makes a difference.
If still crashing, capture from the Apache error log ALL messages from
time just before you made request until after all the messages output
from making the request.
Pay special attention to whether you see a message about 'Segmentation Fault'.
Post this messages to the list.
3. Wrap your WSGI application with first logging middleware described in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response
This will cause details of request and response to be logged into
Apache error log and can confirm whether the web application is
actually returning anything or whether it is hanging of whether
process is crashing.
Post the messages logged into error log for this.
Based on above may be able to say what is happening and potentially
suggest other things to do if process is crashing.
Graham