Xinetd resurrection

[Steve Grubb]

On Friday 18 September 2009 06:04:43 am Jan Safranek wrote:
> Don't forget to announce the fork on xinetd mailing list.

Its dead. 

> Also, contacting orginal xinetd maintainer if he is willing to contribute, 
> e.g. with xinetd.org domain :).

I am/was the co-maintainer of xinetd. I hearby relinquish all interest in 
xinetd. I have more than enough projects to keep me busy. I also think that 
the reason xinetd came into existence in the first place has long since passed. 
The original intent was to save memory by not having half a dozen servers 
running. (Remember the early 1990's systems.) Today we have plenty of memory 
in computers and the reason for xinetd is gone.

A note to anyone taking this on. We had people running xinetd on very old 
hardware and they expected it to work. If you are going to drop support for 
the old systems, you might want to name the project xinetd-ng or something to 
signify that its not the same old code. Also, you can cleanhouse with that 
portable library and other crazy stuff in the lib directory.

There is one serious bug in xinetd that needs fixing that you might want to 
address. If you have a "wait" service, xinetd does not accept the connection - 
this is by design. It passes the descriptor for the connection to the child 
which is required to accept the connection before using the socket. If that 
program does not accept the connection, it likely cannot read anything and 
will exit. Xinetd re-enables the listening descriptor and sees the same 
descriptor in ready state and spawns the same child to handle it. Round and 
round we go eating up CPU. There needs to be kernel support for looking at a 
descriptor and seeing its state so that this problem can be handled 
gracefully. As far as I know, this problem is unique to inetd programs since 
they pass descriptors to other programs for use.

I also think you might want to contact people in altlinux or openwall and see 
if they are interested in this new project. They expressed some interest in 
the past - especially if the code footprint can be reduced. They want a 
smaller, leaner xinetd.

Good Luck...

-Steve