[mod_python] kernel panic - Attempting to free lock with active waiting queue

Jim Gallacher jg.lists at sympatico.ca
Mon Aug 15 17:55:10 EDT 2005

Huzaifa Tapal wrote:
> I am not using mod_python Session management in my handler.
> Huzaifa

I don't think that your problems are related to init_mutexes then. The 
mutexes are used for 3 things: locking session objects, locking the dbm
file used for storing session data (in the case of DbmSession), and 
locking the dbm file used as the psp cache. Oh, I guess I didn't ask you 
that: are you using psp?

I may be wrong, but I don't see how just initializing the mutexes at 
mod_python startup could be exercising the bug in the 2.6.12 kernel. You 
could always try compiling with MAX_LOCKS=2 (defined in 
src/include/mod_python.h) and see what happens, but I would be suprised 
if it made a difference. Heck you could even try MAX_LOCKS=0, but I'm 
not sure what might happen there. I'm pretty sure if you do call 
_apache._global_lock() with MAX_LOCKS=0 you'll seg fault as I don't 
thing we check to see if glb->nlocks==0. Please note that in version 3.2 
you will be able to specify MAX_LOCKS using configure 
--with-max-locks=<some integer>.


> Jim Gallacher wrote:
>> Huzaifa Tapal wrote:
>>> No, no content was being served from ns, however, our sys dev team 
>>> here did some investigation and here is what the found:
>>> in mod_python.c for the  apr_status_t init_mutexes() method which I 
>>> believe gets called for the Memory Session management, apache's 
>>> apr_global_mutex_create() locking mechanism is being used to lock a 
>>> file on the filesystem in cases of a mulit-process and multi-threaded 
>>> apache configuration to share the session between different child 
>>> processes.  Apache's  apr_status_t init_mutexes() method is covered 
>>> with flock() the handling of which in the debian kernel has 
>>> a bug under severe cases.
>>> In our testing, under a very, very heavy load of over 800 concurrent 
>>> connections using a jython-based tool called grinder, a race 
>>> condiditon is happening at which point the kernel is panicking.  The 
>>> solution to this problem as we see it is to either change apache's  
>>> apr_status_t init_mutexes() method ot use fnctl lock instead of 
>>> flocks, or run apache with only one process at all times.
>>> In the meantime, we are going to still moderately load test our 
>>> cluster through out the weekend and see if we can replicate the panic 
>>> under a moderate load but a long duration of time.
>> Are you using sessions in your test handler? If so I've got some ideas 
>> I can share, but I don't want to confuse the issue if you are not 
>> actually using sessions.
>> The short answer is that init_mutexes() does indeed allocate mutexes 
>> for session locking support.
>> Jim
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python

More information about the Mod_python mailing list