The problem is that Python only triggers signal handlers fromthe main thread, which in daemon mode or embedded mode with worker MPM is always parked doing nothing but waiting for process to be shutdown. Thus the signal handler never gets triggered even it is register by Python.
Even in embedded mode with preform MPM it Is dependent on Python code actually being run and that would only occur the next time a request is handled. End result is that signals aren't really usable from Python code level. Also be aware that mod_wsgi 4.0 will start to use sigusr1 for user graceful restarts of daemon mode processes. Graham On Monday, 7 March 2011, Carl Nobile <[email protected]> wrote: > Jason, > > Python, threads, and signals are always problematic. If I remember correctly > the parent thread is the only thread that receives the signal, in order to > get the remaining threads to respond to the signal the parent thread needs to > kill it's own sub-threads. It's been a while since I have had to do this > however. Also, mod_wsgi doesn't use python threads it uses libpthread.so, so > I'm also not sure how this plays into the mix either. > > Long story short I remember Graham saying that there are issues with using > signals. Try and look through old posts for comments about this issue. > > ~Carl > > On Mon, Mar 7, 2011 at 11:16 AM, Jason Connor <[email protected]> wrote: > Hi All, > > Some background: I'm writing a large rest server application using web.py and > mod_wsgi. I've deployed the application as a wsgi daemon with 1 process and > multiple threads. This allows me to use a global task queue for running > asynchronous tasks. > > I'm currently trying to implement a server-side debugger by sending a signal > to the wsgi application (sigusr2). I've turned off the signal, stdin, and > stdout restrictions (WSGIRestrict(Signal|Stdin|Stdout) Off). I've setup a > signal handler in the main thread using an import script. The callback opens > and attaches to 2 named pipes in /tmp. The command line script that sends the > signal also opens the pipes. > > However, once I send the signal, nothing happens. The wsgi application > completely ignores and continues to answer requests. If I don't set the > signal handler, when I deliver the signal the application gets interrupted > and mod_wsgi conveniently restarts it. I'm having a hard time figuring out > what is going on as there is no messages logged by apache or even my app > (I've got logging in the signal handler callback). > > Disclaimer: I've read a few threads in this group on this topic. And I've > made use of > * sending extra http request to try and deliver the signal > * start a background thread that wakes up every so often and then goes back > to sleep to trigger the signal delivery > > Any comments by anyone with experience delivering signals to a wsgi daemon > process are welcome. I'm finally out of ideas and would love a new angle to > attack this problem from. > > Thank you, > Jason L Connor > > > > > -- > 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. > > > -- > ------------------------------------------------------------------------------- > Carl J. Nobile (Software Engineer) > [email protected] > ------------------------------------------------------------------------------- > > > -- > 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.
