On Fri, 2008-11-21 at 14:30 -0500, Carolyn Beeton wrote: > There was a bit of discussion earlier this summer (see > http://article.gmane.org/gmane.comp.voip.sipx.devel/11076) about > running allowing supervisor to run "commands" rather than "services" > at the request of sipXconfig (i.e. via xmlrpc). Scott mentioned > creating an issue for a sipXecs-command definition, but I'm not sure > whether that actually happened. > > We now have at least two examples of this: > > - the package update stuff that Raymond is working on, and > - run configtest independently which I am starting to look at > > At the time of the earlier discussion it was mentioned that being able > to execute sipx-snapshot on a remote machine would be another example.
At this very late stage in the release, I'd prefer that we solve our immediate problems with narrow one-off solutions. The general problem of command execution has a lot of facets, and I'd rather not constrain ourselves to be backward-compatible with something we don't have time to properly think through. > Raymond and I are wrestling with some of the same issues and we have > some different ideas about how to do this. > > Raymond is proposing launching a command, redirecting its output to a > file, and providing an interface to return the contents of the file. > He is wrestling with how to prevent the same command from being run > more than once at the same time. The package update command requires > sudo access, and involves shutting down the entire sipxpbx. It _should_ be possible to do the upgrade with things running (there are various ways the upgrade itself can mess this up, but with reasonable care it's ok). Then at the end, if the upgrade returns success just run the service restart command. > I had thought of running my command (configtest) under the control of > a task in supervisor, and collecting the output the same way we > collect stdout/stderr for the processes. Since the pid executing the > command would be under the control of the supervisor, it would be > easier to prevent it from being executed twice. However the command > wouldn't survive a shutdown of sipxpbx. (That's a good thing for me) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
