On Thu, 2008-11-13 at 08:36 -0500, Carolyn Beeton wrote: > Not that I don't have confidence in the supervisor, but... I'd rather > have this dicussion now than after a failure at a customer site. > > The main consequence of a crash in the supervisor is that the child > processes are stranded with no parent and no way of shutting them down. > > Relaunching the supervisor service then results in double copies of the > processes, some of which fail (e.g. can't bind to address). > > ==> sipxpbx script should shutdown any pids left running (in sipx > pidfiles) if (or after) supervisor is gone, on stop or restart
Why not have supervisor do that at startup? Look for pid files before it starts anything and clean up any it finds that have processes that match them. > ==> sipxpbx script should warn (and abort?) if any sipx pidfiles are > present on start? There's nothing the user can do with the information (even if anyone is watching the console to see it), so I don't think this is a good alternative. > ==> something should be supervising the supervisor? dare I say a > Watchdog? Let's not go there - infinite recursion. > supervisor is doing quite a lot: all xmlrpc, file replication etc, > alarms, as well as launching and monitoring processes; any crash in any > of the libs can bring it down. Confidence, 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
