> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Al Campbell (JIRA) > Sent: Tuesday, November 04, 2008 6:38 PM > To: [EMAIL PROTECTED] > Subject: [SFtrack] Updated: (XECS-1825) Improved process > start/stop/control system from sipXsupervisor > > > [ > http://track.sipfoundry.org/browse/XECS-1825?page=com.atlassia n.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Al Campbell updated XECS-1825: > ------------------------------ > > Fix Version/s: 3.11.8 > > > Improved process start/stop/control system from sipXsupervisor > > -------------------------------------------------------------- > > > > Key: XECS-1825 > > URL: http://track.sipfoundry.org/browse/XECS-1825 > > Project: sipXecs > > Issue Type: New Feature > > Components: sipXcommsrvLib, sipXsupervisor > > Reporter: Carolyn Beeton > > Assignee: Carolyn Beeton > > Fix For: 3.11.8 > > > > Original Estimate: 2 weeks > > Remaining Estimate: 2 weeks > > > > As sipXsupervisor is the parent process for all the other > sipXecs processes, it has a parent/child relationship with > them. This means that after sipXsupervisor calls fork(2), > the child process inherits all the file descriptors that are > open at the time of the fork(2). Normally, the child process > then closes all the file descriptors it doesn't need (ALL of > them!) and redirects STDIN/STDOUT and STDERR (descriptors > number 0, 1, and 2) to /dev/null. Then it calls exec(2) to > load the new executable image. > > Instead of setting STDERR to /dev/null, sipXsupervisor can > call pipe(2) or socketpair(2) to create two new file > descriptors. One is for the parent to keep, the other is > dup2(2)'ed as FD 2 (STDERR) after the fork(2). Thus, the > child now has a direct pipe to the parent, and anything the > child writes to STDERR will be readable by the sipXsupervisor > on the corresponding file descriptor. > > If sipXsupervisor monitors these file descriptors from the > children for activity (most likly using poll(2)) it can read > from them when there is something written. It can then log > that message from the child or take other action (like > raising an alarm). As it knows what child sent the message > (there's a specific FD for each child process), it can > correlate who said what when. So sipXsupervisor becomes the > "logger of last resort", as anything a child emits on STDERR > will be captured and logged. > > In addition, sipXsupervisor can create another > pipe/socketpair for each child's STDIN. This can be used to > send control messages to the child. Currently, > sipXsupervisor uses SIGNALs to shutdown the child. This can > be a bit harsh on the child process. Java, for example, > still has no effective means of catching signals and letting > the user code shutdown cleanly. If instead of signals we > switch to a standardized set of messages sent to the > process's STDIN, it would enable cleaner shutdowns, and also > give greater ability to control the process than we currently have. > > For example, currently when the configuration for a process > changes, the process is killed and restarted. Given a > message on STDIN that notified the process of a configuration > change, the process itself could either handle the new > configuration on-the-fly, or restart itself if that was what > was needed. But it puts the process in control of that > decision. And if needs to restart, it can report to the > parent why it is restarting. > > Another possiblity is that the processes start up and then > wait for a command from sipXsupervisor to continue reading > their configuration. This allows for sipXconfig to get up > and running and write out a new configuration, which then > tells sipXsupervisor, which then tells the children it's okay > to start up now. This can actually be done directly inside > sipXsupervisor code after the fork(2), but before the > exec(2). So a new startup scheme could be established > without the need for changing any of the other processes. > > On thing to note: if using socketpair(2) instead of > pipe(2), then the file descriptors are actually > bi-directional. This allows for a full command/response > protocol to be used on STDIN (yep, even though it is named > STDIN, it can be bi-directional. It really is just a file > descriptor that happens to have the special value 0). So > sipXsupervisor could query the children to find their status, > and the responses could come back on the same FD. > > And of course, there's no reason to leave STDOUT out in the > cold. If sipXsupervisor sets up a pipe/socketpair for FD 1, > then anything the process "prints" to STDOUT can be captured > as well. This can be useful for logging output from startup > scripts, which don't use the normal logging subsystems. > > --
Do we really want to do this in 4.0? We have the capturing stdout/stderr of the children part already, and we have other ways of controlling processes. This proposal involves redesign of each process to read from stdin. This issue was cloned to capture the design proposal, while the logging part was implemented in 3.11.7. 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
