Cool. Why reinvent the wheel? :) On Thu, Oct 7, 2010 at 8:29 AM, Bruce Frederiksen <[email protected]>wrote:
> Hi Roger, > > After checking out how xinetd works on Linux, I'm seeing that it copies the > new connection to stdin, stdout and stderr. > > We're going to give xinetd a try first before diving into a patch here. > > Thanks for the help! > > -Bruce > > > > On Fri, Sep 24, 2010 at 12:50 PM, Roger Hoover <[email protected]>wrote: > >> 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
