Subject: Re: xinetd port (Was Re: Mail server questions.)
To: Jeremy C. Reed <reed@reedmedia.net>
From: None <netbsd99@sudog.com>
List: netbsd-help
Date: 12/02/2002 16:12:55
On Monday 02 December 2002 15:48, Jeremy C. Reed wrote:
> On Mon, 2 Dec 2002 netbsd99@sudog.com wrote:
>
> > xinetd is evil. It doesn't do the right thing when forking off daemons.
> > stderr ends up being mapped to the socket--if the application isn't
> > designed with xinetd's handling of stderr in mind, a single error
> > message can disrupt protocols in a very messy fashion. :-)
>
> What is an example?
Okay--take a server that uses TCP RPC. Spawn it from inetd. Spawn a
misbehaving sub-program from the server. Write to stderr from sub-program,
which expects it to be sent to a log or to console and presto! Broken RPC
channel.
> > .. err .. I forget: does inetd do this too?
>
> pop3 server lauched via inetd as shown with fstat(1):
>
> root vm-pop3d 1336 0* internet stream tcp c08a9178 127.0.0.1:110
<-> 127.0.0.1:63775
> root vm-pop3d 1336 1* internet stream tcp c08a9178 127.0.0.1:110
<-> 127.0.0.1:63775
> root vm-pop3d 1336 2* internet stream tcp c08a9178 127.0.0.1:110
<-> 127.0.0.1:63775
Yuck. Oh well. I suppose it's arguable what's "correct" behaviour, since that
means that you're joining stderr/out without regard to whether this is what
the user actually wants or not. Maybe the user (me in this case) wants stderr
piped instead to /dev/null or a logfile? I have to do it myself--which means
inetd assumes I have access I may not have (source for example, or an
unnecessary wrapper script maybe) to make a change to accommodate *inetd*
instead of being able to tell inetd (or xinetd, shudder) to accommodate
itself to me.
> > Also, xinetd is unecessarily complex to configure.
>
> I agree (but xinetd does offer many options not available in inetd).
>
> Anyways, there are many packages I don't use in pkgsrc -- and some
> packages in pkgsrc that I don't agree with, but I am sure that someone
> else finds them useful for some reason or another.
Oh, I'm sure it'd be great as a pkgsrc. :-) I'm just trying to sow the seeds
of dissent if the very unfortunate possibility arises that xinetd replaces
inetd in the base install.