On 9 December 2011 02:26, Michael P. Jung <[email protected]> wrote: >> WSGIApplication %{GLOBAL} > > You meant "WSGIApplicationGroup %{GLOBAL}" > > I totally forgot about the sub interpreter issues. I haven't had any > troubles with pymongo and subinterpreters in the past. Setting the > Application Group to Global helped for Trac installations, but > unfortunately in this case it doesn't change a thing. > >> The mod_wsgi code does send SIGINT's to itself, but messages would >> have to imply that it is getting stuck in some sort of loop to be >> continually sending them to itself. The only place I could see that >> easily happening is if in the monitor thread, which is what handles >> deadlock timeout etc. Not sure how it could go haywire though and >> cause a rapid SIGINT loop. Worst case it should only generate a SIGINT >> once a second and that only in a state where the main thread which is >> waiting on reading off that fd=5 of socketpair was failing to read the >> "X" and not exit the process. It would take something closing and >> replacing fd=5 to really screw with that. > > The SIGINT loop is not rapid. It occurs about once per second but > doesn't stop. Apache log stays quiet. After some time Apache reports a > timed out request. The WSGI daemon stays unuseable and the only way to > fix it is to reload/restart Apache or kill -9 the WSGI daemon.
So the inactivity/deadlock timeout loop is doing what it would if a timeout occurred. If LogLevel is info or greater it should have logged if it was triggering because of inactivity or deadlock though. For the loop to keep going means process didn't shutdown. This would require two things. First is that request threads didn't exit and then the shutdown timeout thread failing to run and expire and forcible kill process by calling exit(). What are options for WSGIDaemonProcess you are using? I could also implement a fail safe in the inactivity/deadlock timeout loop so once in its one second SIGINT loop that if goes on too long it also calls exit(). This doesn't explain why shutdown timeout thread failed. If it had got to point of shutdown timeout thread being created then should have logged 'Shutdown requested'. If it didn't then means the socketpair() loop communicating from signal handler to main thread has been busted. The second exit() failsafe could compensate for that. So two questions. Was it a deadlock that occurred and why did socketpair() fail? Graham >> LogLevel debug >> >> and: >> >> WSGIVerboseDebugging On > > Right now we depend on a working setup so we simply disabled the C > extensions of pymongo. This fixed the issue for us. I'll try to dig > deeper into this issue in the future as we would prefer to use pymongo > with the C extension enabled. > > > Thanks for the help, > Michael > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
