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

I am not using mod_python Session management in my handler. 

Huzaifa

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 2.6.12.4 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
>
>