Since the upgrade to 2.3.9, xinetd has become unable to cope with rate restriction being exceeded. Jan 10 16:45:05 potato xinetd[27200]: Deactivating service smtp due to excessive incoming connections. Restarting in 10 seconds. Jan 10 16:45:15 potato xinetd[27200]: Activating service smtp Jan 10 16:46:04 potato xinetd[27200]: file descriptor of service smtp has been closed Jan 10 16:46:04 potato xinetd[27200]: select reported EBADF but no bad file descriptors were found and at that point, it stops listening for new incoming connections altogether. Worse, I get to see: tcp 7 0 my.ip.ad.dr:25 204.152.186.51:3293 CLOSE_WAIT 14679/leafnode tcp 1 0 my.ip.ad.dr:25 137.73.66.5:47948 CLOSE_WAIT 14679/leafnode tcp 1 0 my.ip.ad.dr:25 168.100.1.4:3451 CLOSE_WAIT 14679/leafnode leafnode handling smtp connections? That's news. :] This has happened 3x over today alone. xinetd.conf contains: # instances = 4 # per_source = 2 # cps = 3 10 # max_load = 3 # rlimit_cpu = 40 # } the package was compiled with CFLAGS="-O2 -mcpu=i686 -march=pentium", and USE="x86 oss 3dnow crypt encode jpeg libg++ mikmod mmx ncurses nls oggvorbis pdflib png spell truetype xml2 zlib gdbm berkdb slang readline tcpd pam libwww ssl python esd aalib -apm -arts -avi -cups -gif -gnome -gpm -gtk guile -imlib ipv6 -java -kde lcms leim mbox -motif -mpeg odbc -opengl perl pic postgres -qt -qtmt -quicktime ruby -sdl sse -svga tiff -X -xmms -xv"
who wants to repair/maintain xinetd?
is this fixed in 2.3.12 ?
normal xinetd function configure your system
This was not an invalid bug. xinetd passing connections to the wrong process for the job was a serious fault with potential security ramifications. Fortunately, more recent builds of xinetd (tested subsequent to the mem-leak vulnerability) do not exhibit the problem, therefore I'm prepared to consider it closed for the time being.
