I am indeed sending the signal to the daemon process; as such, the explanation you give is consistent with observed behavior.
My goal, similar to that expressed by Jeff in his prior thread on the subject, is to provide a means to dump a stack trace to stderr on request, allowing a glimpse into the state of of an unresponsive thread; with OS signals unavailable, I'm at a loss for ways to do this short of a script using gdb macros to attach and introspect -- perhaps an even more fragile approach, as the pystack macro provided by the Python team is known to occasionally crash the interpreter. (Well -- perhaps this isn't the *only* way to accomplish such a thing. For instance, one could have each daemon process spawn a separate thread which opens a socket, perhaps named by PID, and block on a 1- byte read, dumping a stack trace of all other threads in its view whenever that socket is written to. However, the obvious drawbacks re: implementation complexity and overhead make me hesitant to pursue that approach). On Sep 14, 7:19 pm, Graham Dumpleton <[email protected]> wrote: > 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 > > athttp://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.
