Kelly Yancey wrote: > Since the child processes are currently running in their own sessions > and process groups (due daemonizing them after spawn) I would venture > that the cause is simply that signals aren't propogated across process > groups. Moving the daemonization to before the subprocess is spawned > should fix the problem (since the children would be in the same process > group as the daemonized monitor process).
I think actually the problem in the email is different; it's simple a logic error where daemonizing happens after the monitor is started, so the process that is being monitor disappears due to daemonization. And then it tries to restart the process, which disappears again and so on. But coincidentally I did happen to just be working on the problem you describe. > That said, I had a similar problem quite some time back with > subprocesses not receiving signals so they would not shut down when the > parent did. In my case, I was forking the processes from C, but the > principle is the same: exec*() under POSIX only resets signals that are > not ignored. So if the parent ignores some signal and then forks > another process and that process calls exec*() to load a new program > image, the new program won't receive the ignored signal either. Python's > os.spawn*() family of functions do exactly this fork()/exec() pair; I > haven't looked, but I doubt they reset the signals for you automatically. > Here is the C code I used to workaround the problem. In my case, I > put it between the fork() and the exec() in my equivalent of python's > os.spawn*(), but you can put it anywhere in the child processes' code > for the same effect. It looks like the python signal module should make > porting to python pretty straightforward: > > /* > * Reset the child's signal handlers back to their defaults. > * The execvp() call below resets only signals that are not > * being ignored, hence we need this loop to get the rest. > * XXX There has got to be a better way to do this! > */ > for (i = 0; i < NSIG; i++) > signal(i, SIG_DFL); > > Completely untested, but I would expect the logic to look like this in > Python: > import signal > for i in range(signal.NSIG): > signal.signal(i, signal.SIG_DFL) > > By the way, I have never found a better way to do it. :) Of course, > all of this presumes that the parent process is setting signal's handler > to SIG_IGN somewhere, meaning that it expects to ignore the signal, but > you don't want the children to ignore the same signal. I haven't looked > at the monitor code in Paste yet to know. It isn't very common that > this is the case, but I thought I should mention it anyway. Would signal.SIG_DFL pass the signal to children? That's the issue I'm having. I have code now that catches SIGTERM and then passes that to the child process, but I imagine it would be good if every signal was passed through. But I'm a little unsure how best to do that. For some reason SIGTERM was killing the process without raising SystemExit, which meant finally blocks were not called. But ideally SIGHUP or whatever other signal would also get passed through. At the same time, I don't think I want to actually swallow those signals in the monitoring process. Or do I want to swallow them? I'm not sure. > By the way, Ian, J.J. had suggested I send you a patch for issue > (which I haven't done yet), but I found a subtle bug in Paste's > Accept-Language parsing a couple of weeks ago. The description is in my > blog at: > http://kbyanc.blogspot.com/2007/04/more-i-dig-through-code-more-paste-is.html > > The fix is pretty trivial (and detailed in my blog). I'm sorry I've > been a lazy bum and not sent you patches yet. Sure; I think I did what you suggested in r6482 (just removed the regex check) -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
