Let us know if it works out. On Thu, Oct 7, 2010 at 10:35, Roger Hoover <roger.hoo...@gmail.com> wrote:
> Cool. Why reinvent the wheel? :) > > > On Thu, Oct 7, 2010 at 8:29 AM, Bruce Frederiksen <dangy...@gmail.com>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 <roger.hoo...@gmail.com>wrote: >> >>> Hi Bruce, >>> >>> On Fri, Sep 24, 2010 at 6:18 AM, Bruce Frederiksen >>> <dangy...@gmail.com>wrote: >>> >>>> Hi Roger, >>>> >>>> On Thu, Sep 23, 2010 at 10:13 PM, Roger Hoover >>>> <roger.hoo...@gmail.com>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 > Supervisor-users@lists.supervisord.org > http://lists.supervisord.org/mailman/listinfo/supervisor-users > > -- Jason Koppe jko...@indeed.com (210) 445-8242
_______________________________________________ Supervisor-users mailing list Supervisor-users@lists.supervisord.org http://lists.supervisord.org/mailman/listinfo/supervisor-users
