On Tue, 2008-12-09 at 14:23 -0500, Andy Spitzer wrote: > Woof! > > On Tue, 09 Dec 2008 14:02:42 -0500, Carolyn Beeton <[EMAIL PROTECTED]> wrote: > > > Woof commented this morning on another way of recovering from a > > supervisor crash... something about forking a child but dong anything > > unless/until the parent dies and then not exec'ing but running as a copy > > of itself (i.e. a new supervisor)... > > Yep. Call fork(), have the "child" hander do the "wait for parent to > die, see if it should restart" trick. If it is to restart, then it > can promote it self by calling main(). This essentually creates two > copies of the process, one of them will continue and do whatever it is > supposed to do (sipXsupervisor stuff, in this case), the other becomes > the "supervisor in waiting" and will wait for the parent to die, and > then take over. > > > I don't think this removes the need > > to restart the supervisor > > Yes, it does, as the "supervisor in waiting" is already started (as > the child of the previous supervisor, with all the rights and > privledges thereunto). All it needs to do to be promoted to current > supervisor is call main(). > > > and all its original children, > > Yes, the original children need to be killed and be re-born. The only > good orphan is a dead orphan. But the supervisor code already handles > that case, right? So when the "supervisor in waiting" promote's > itself when it calls main(), the first thing it does is create a > "supervisor in waiting", check if any of the previous children are > still around and commit murder on them if so, (you can't have your > predecessor's children around to get in the way, you know, even if > they are your siblings), and then install his own children in their > stead.
This would mean that any cleanup implemented in the startup script itself would not be redone.... still, might be worth a try. We'd also need to move the writing of the supervisor pid file into the supervisor code (it's currently done in the wrapper script) so that the pid file value would be correct), but that's probably a good idea anyway. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
