On Wed, 2008-10-15 at 16:29 -0400, Damian Krzeminski wrote: > So sipXsupervisor (which knows exactly which files and when are pushed > since it implements XML/RPC AP) should check if affected service is running > and start it if it's not. > If the service is running it should notify it about configuration change > (or restart it if the service cannot dynamically update configuration).
If the sipXsupervisor believes that a process is Enabled, but that process is not running due to a failure of one of the checks (existence of required resources, mismatched version, or configtest failure), then it will trigger a recheck whenever anything is updated. So, if a process is Enabled but not yet started because a configuration file is missing, then replicating that file will cause a new set of checks - if they all pass, then the process will be started. Replicating a configuration file for a running process does _not_ trigger new checks, nor does it restart the process. The process will be restarted only if sipXconfig explicitly orders that restart. Hopefully, in some future version we'll have a 'reread configuration' primitive that all services will support, but even then I think it will have to be an explicit sipXconfig action so that changes that affect multiple files can be activated in a controlled way. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
