What process are you sending the signal to? >From memory such signal fiddles will not work with daemon mode processes as the main thread which handles signals in Python is never used in daemon mode and all requests are handled in secondary foreign threads.
What are you wanting to do in response to the signal anyway? In general I highly recommend not trying to do anything with signals as you don't control the process execution environment, Apache does, and fiddling with signals can upset the operation of Apache. Graham On 15 September 2010 03:29, Charles Duffy <[email protected]> wrote: > Howdy! I'm trying to implement something similar to what Jeff Jenkins > described in the thread "mod_wsgi and signals" (http:// > groups.google.com/group/modwsgi/browse_frm/thread/353e2e782921d5d3/ > d377935ea65e985c). The limitations described in that thread (deferred > delivery for threads sitting in the Apache main loop rather than > Python code) are acceptable for my intended use case. > > My setup should be fairly simple: > - I'm using the prefork MPM with Apache 2.2.3 on CentOS, against a > locally built Python 2.6.4 > - I'm currently targeting SIGUSR2 -- as (1) its default action is to > be ignored, and (2) Apache doesn't use it for anything as far as I > know. > - I'm calling signal.signal() directly within the .wsgi file specified > by a "WSGIDaemonProcess" directive. > > However, something seems to be very wrong: > > - Even with an explicit "WSGIRestrictSignal On", the warning > indicating that a signal handler registration was attempted and > suppressed is not logged -- even with "LogLevel info" set. Calling > signal.signal() twice returns the previously-set handler, implying > that the handler is in fact put in place. > - While I'm using USR2, for which the default action is ignore, the > child process exits when the signal is received -- whether or not I've > run my code registering this handler. The associated log message is > akin to the following: [notice] child pid 54321 exit signal User > defined signal 2 (12) > - Calling signal.signal() to register the handler returns that it's > already using the desired function, but sending the process the > relevant signal still causes it to die (again, contrary to the usual > default disposition for SIGUSR2, which is SIG_IGN). > > I've tried to follow in Jeff's footsteps and switching to SIGQUIT; > however, this followed its default (erroneous exit) behavior. > > > Any pointers? > > -- > 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.
