Xinetd resurrection
Steve Grubb
sgrubb at redhat.com
Fri Sep 18 12:24:18 UTC 2009
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
More information about the fedora-devel-list
mailing list