mod_wsgi issue: solved

[David Malcolm]

I've been trying to deploy rpmgrok (a Turbogears 1 app [1]) behind
mod_wsgi, and finally figured out why mod_wsgi stopped working when I
added a WSGIProcessGroup directive (which avoids having to start a new
process per http request)

I know bpeck has had similar issues with his "beaker" code [2]

It was working on publictest14.fp.org, but not on my local workstation
(both RHEL-5 running mod_wsgi from EPEL).

Attempts to browse led to no response coming from httpd, and no log.

It turned out, I had mod_python installed on the box.

Upon disabling "LoadModule python_module modules/mod_python.so"
from /etc/httpd/conf.d/python.conf it worked.

Known issue?  http://code.google.com/p/modwsgi/wiki/InstallationIssues
describes another mod_wsgi/mod_python incompatibility, but the symptoms
seem different [3]


Hope this helps
Dave

[1] https://fedorahosted.org/rpmgrok/
[2] https://fedorahosted.org/beaker/
[3] debugging attempts led me to find "stuck" httpd threads waiting
forever for the global interpreter lock, presumably acquired by
mod_python elsewhere in the process:
(gdb) bt
#0  0x005bf402 in __kernel_vsyscall ()
#1  0x0018331e in sem_wait at GLIBC_2.0 ()
from /lib/i686/nosegneg/libpthread.so.0
#2  0x01d97f3b in PyThread_acquire_lock ()
from /usr/lib/libpython2.4.so.1.0
#3  0x01d74d57 in PyEval_RestoreThread ()
from /usr/lib/libpython2.4.so.1.0
#4  0x01d9104f in PyGILState_Ensure () from /usr/lib/libpython2.4.so.1.0
#5  0x00c65785 in wsgi_start_process (p=0x918a550, daemon=0x92b91a8) at
mod_wsgi.c:8706
#6  0x00c661b3 in wsgi_hook_init (pconf=0x918a550, ptemp=0x91b8608,
plog=0x91bc618, s=0x918c3f0) at mod_wsgi.c:8919
#7  0x00c27783 in ap_run_post_config (pconf=0x918a550, plog=0x91b8608,
ptemp=0x91bc618, s=0x918c3f0)
at /usr/src/debug/httpd-2.2.3/server/config.c:91
#8  0x00c1311d in main (argc=152602056, argv=0x9281448)
at /usr/src/debug/httpd-2.2.3/server/main.c:706

and:
 grep /proc/$PID/maps  mod_
showed mod_python to be loaded.