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

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