mod_wsgi issue: solved
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(a)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.