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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
