Woof wrote:
> On Tue, 30 Sep 2008 10:20:13 -0400, Raymond Dans > <[EMAIL PROTECTED]> wrote: > > > > > The "Launch" method of osProcessLinux sets things up to ignore any > > child signals. > > This was done to simplify process handling and make sure no > zombies are left to walk the earth! > Understood, however, doing the wait or waitpid will get rid of the zombies as well. > > > we were trying to use the "Launch" and "wait" methods in > > osProcessLinux to Launch an application and then wait for > its result > > to provide this back to the Supervisor. Unfortunately, we > would never > > actually get back the result set by the child process. > > What would you do with the result set if you had it? Does > the result of the exit change your behavior in anyway (all > the result can really tell you is what signal shutdown the > process if it didn't exit gracefully, such as SIGABRT). Do > you intend to act on that information? As it stands, > waitpid() will tell you if the process died (as it no longer > exists), just not the "status" value of exit(). As Scott stated, we need to get the results when doing something like a configtest. > > > I would like to propose a change to the "Launch" method so > that we do > > NOT set things up to ignore the child signals so that the wait > > function will then be able to obtain the child process > result/return > > code. When the waitpid is used and the process returns, > the process > > will be cleaned up automatically after obtaining the result. > > True, but then the SIGCHLD needs to be handled. Most of the > sipX processes now use a signal thread to catch and handle > ALL outside signals. This protects the other threads from > handling random signals that may cause trouble (as they did > in code that used the IMDB). The SIGCHLD needs to be handled > in ALL sipX processes then. By ignoring SIGCHLD, it solved > that problem for all processes. If you change that, then you > have to track down and find all processes that use > sipXportLib and make sure they correctly handle SIGCHLD. > Currently, those processes will exit on any signal, so when a > child dies, and SIGCHLD is sent to the parent, the parent > will exit as well. > Will the default signal handler not take care of it? At any rate, I've only been able to find one place in the code that uses the Launch capability and I believe it will be thrown away with the new SipxSupervisor. > > > If there are no objections, I'll open a new JIRA issue to > change this > > so that I can proceed with the proper solution to XECS-1661. > > I'm not objecting--but you'd have to convince me the value of > collecting the exit() status is worth the effort. > > --Woof! > Unless there is some other existing way of getting the return code from the process, I don't know how we would do it in a short timeframe. Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
