> -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Thursday, November 13, 2008 10:08 AM > To: Spitzer, Andy (BL60:9D30) > Cc: Beeton, Carolyn (CAR:9D60); [EMAIL PROTECTED] > Subject: Re: [sipX-dev] consequences of supervisor crash > > On Thu, 2008-11-13 at 09:34 -0500, Andy Spitzer wrote: > > One way to prevent this is have the "child" processes detect that > > STDIN closed, and when that happens they commit suicide. > As stdin is > > inherited from the parent as a pipe, it closes when the > parent process > > closes it (which it would never do, normally), or when the parent > > dies. Orphans cause nothing but trouble in our society, > and would be > > best served to kill themselves! (What a great quote to get me in > > trouble when taken out of context!) > > This is a good idea, as it Does The Right Thing when a > desperate user does "kill -9" on the supervisor to try to > clean up a sipX that he's gotten into some bad state. > > I think we should do a combination of this idea with having > the supervisor detect and clean up any existing PID files > upon startup (which is what we already do, yes?). >
Woof's and Dale's comments intruiged me: the children (could) know when the supervisor is gone. What if one of them could restart the supervisor? So I wrote a process defn file and a script for a supervisor watcher. It is duly launched as a child process, but all it does is (in its script) read from stdin. If shut down properly, it never does anything. But if it returns from the read, then supervisor is gone: so it invokes /etc/init.d/sipxpbx restart. (I extended OsProcessLinux to create a stdin pipe). I can now demonstrate a successful automatic relaunch after a crash, or even even after "kill -9" of supervisor. Is this worth considering? Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
