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.