Hi Bruce, On Fri, Sep 24, 2010 at 6:18 AM, Bruce Frederiksen <[email protected]>wrote:
> Hi Roger, > > On Thu, Sep 23, 2010 at 10:13 PM, Roger Hoover <[email protected]>wrote: > >> Got it. Thanks for explaining. I think this is the way that inetd/xinetd >> work. >> > > Yeah, I'm not sure of how inetd/xinetd pass the new connection to the > child. Sounds like the child gets 3 copies of the connection as > stdin/stdout/stderr? This doesn't make much sense to me. > I think you're right. My quick googling said 0 and 1 but maybe it's stderr as well. > > >> OK. This makes sense. As you say, it's a different model from FastCGI so >> I think you should create a new type of supervisord "program", something >> like "inetd-program", "superserver-program" (inetd is sometimes called the >> superserver) or "fork-program" (as opposed to prefork). I think your >> servers would be compatible with inetd so that might be a good name. >> > > Along these lines, doesn't supervisor want to use stdin/out/err for it's > own purposes (event mechanism and logging support)? So would it make more > sense to pass the socket as fd 3? I see the fcgi-program code passing the > connection as fd 0, but I guess that's to mimic how fcgi works, rather than > what makes sense for supervisor? > > Right. The FCGI spec requires to socket to be passed as fd 0 but as you said that doesn't have to be the case here. Passing it as fd 3 would leave those other file descriptors open for other purposes. However, I tend to think there are cleaner ways to do both logging and message passing between processes. Being able to listen and react to supervisord events is an awesome feature but there are other tools for passing application messages between processes and in my opinion that functionality doesn't belong in the process manager. I'd be ok with supporting a "standard" interface. It would allow people to run existing inetd-compatible programs under supervisor if they want. If the inetd spec is fds 0 and 1, then stderr is still open for logging. > I have no requirement to be compatible with inetd/xinetd, so could just as > well use fd 3 as fd 0... > > Am I correct in perceiving a conflict between supervisor compatibility and > inetd/xinetd compatibility? > > Overall, it does not look that complicated. It looks like supervisord >>> has the architecture already in place to support this. >>> >>> >> I think you should be able to follow a similar pattern as I used for >> fcgi-programs and create a new type of program. >> >> > Yes, I think so. Should be able to (re)use a lot of your code, which will > make this easier. :-) > > Thanks! > > -Bruce >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
