I am wondering how far I should take the "special" process definition file for sipxsupervisor (http://track.sipfoundry.org/browse/XECS-2031).
The first step is to define its own resources there (currently they are farmed out on other unsuspecting processes). In this first step I am not blocking on the resources - if supervisor doesn't start up sipXconfig then it would never unblock. So the supervisor process is very special - it only creates resources, does not track its own state - including blocking on configurationMismatch, ResourceRequired, running configtest, etc., and does not allow start/stop/restart of itself. The question is, should I take the next step of making sipxsupervisor look more like a full blown SipxProcess, with all (or most of) the state transitions that implies? For example, maybe high-level configtest should be run during start-up of sipxsupervisor. It does not appear to run at all during normal operation (only if you explicitly call sipxpbx configtest). [Or should sipxpbx start/restart be running the configtest first?] I could also - possibly - do stop/restart for the supervisor (i.e. the entire sipxpbx). It would be a bit tricky, but I'll do it if it seems the right thing to do. 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
