> -----Original Message-----
> From: Lawrence, Scott (BL60:9D30)
> Sent: Thursday, November 13, 2008 11:42 AM
> To: Beeton, Carolyn (CAR:9D60)
> Cc: Spitzer, Andy (BL60:9D30); [EMAIL PROTECTED]
> Subject: Re: [sipX-dev] consequences of supervisor crash
>
>
> On Thu, 2008-11-13 at 09:40 -0500, Carolyn Beeton 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!)
> > >
> > >
> > > --Woof!
> > >
> > This sounds like a good idea too. Without the supervisor, no
> > xmlrpc-based communication will work, so having the
> processes continue
> > to limp along is probably not good. Better to shut down
> altogether;
> > someone is bound to notice that!
>
> Wait a minute... the goal is not to cause someone to notice -
> the goal is to allow normal phone system use for as long as
> possible and to restart with minimal disruption.
>
> If the supervisor dies and that causes everything else to
> die, then no one can make calls, some calls in progress are
> dropped, etc...
>
> If the processes just chug along in ignorance until the
> supervisor is restarted (by a shell command or perhaps by
> some super-daemon - perhaps even by "init"), then there is at
> most a brief interrupt when the supervisor kills and restarts
> the orphans (calls to media handling apps are interrupted,
> but all others should ride through fine).
>
yeah. I was thinkging that all xmlrpc would stop working, breaking NAT,
freeswitch, etc. But only the proc-mgmt, alarms, and replication rpc
will stop. So if there is value to life without those, then they can
just stay up until supervisor restarts. Monitoring stdin in the
children was going to require work in each process anyway, so would not
have happened any time soon.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
