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

Huzaifa Tapal huzaifa at hostway.com
Mon Aug 15 12:21:40 EDT 2005

I am not using mod_python Session management in my handler. 


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

More information about the Mod_python mailing list