I am examining the problem in XX-6711. Part of the problem is that once Openfire has failed, it is impossible to restart, except by restarting sipXecs as a whole. The reason is that Openfire leaves a "run" file in /tmp/i4jdaemon__opt_openfire_bin_openfire -- when Openfire starts, it checks whether that file exists, and exits immediately if it does.
This is not a problem when sipXecs starts initially because at sipXecs start, it first runs "sipxopenfire.sh --stop", which runs "openfire stop", which deletes that file. After doing that, sipXecs runs Openfire. But if Openfire fails, sipXecs attempts to restart it by running "sipxopenfire.sh --start", which does not remove the run file. Summary: If Openfire crashes, "sipxopenfire.sh --start" is not sufficient to restart Openfire. This leads to a more general question, though: Is "sipxXXX.sh --start" supposed to be sufficient to restart component XXX? If not, we need to revise how sipXsupervisor handles failed processes. If so, we must ask why sipXecs does "sipxXXX.sh --stop" for every component before starting it. I *think* the answer is that sipXsupervisor has to run "sipxXXX.sh --stop" in order to stop the component, in case it is still running. But if the component's process has terminated (by shutdown or crash), "sipxXXX.sh --start" is intended to be sufficient to restart the component. Comments? Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
