WORKSFORME on a dual P4-xeon 2G, so there must be something specific to your 
configuration that triggers this.  Can you please do a "tar cf /tmp/some-file 
/etc/xinetd.conf /etc/xinetd.d" and attach the output file "/tmp/some-file" to 
this bug? 

Created attachment 93929 [details]
xinetd configuration

Requested by redhat bugzilla xinetd maintainer

I've narrowed it down to our special 'daytime workaround'.
We are checking the availability of the Unix computers here
by (amongst other tests) contacting the daytime TCP port
using netcat and grepping for a reasonable output. Problem
we experienced is, that (x)inetd versions constantly change
their behaviour concerning the builtin daytime service. Either
the line end characters change (e.g. from "\n\r" to "\r\n"
or whatever grrrrrr) or the TCP socket is not closed after
output of the date string so our monitorin hangs, or probably
other changes (don't remember all that stuff). So i decided
not to use the internal daytime implementation any longer
and replace it calling the date command, what is achieved
e.g. by the following xinetd.d/daytime file:


service daytime
{
        flags           = REUSE NAMEINARGS
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = /usr/local/bin/dtdate
        server_args     = dtdate
}

dtdate simply contains:
#!/bin/sh
exec date '+%a %b %e %T %Y'

When i add disable = yes then the problem with the hanging
futex bla system call on SIGUSR2 is gone. One might say, that
this is a very special customer configuration issue and ignore
the problem, but in my opinion it should work like it did before.

As soon as it finishes building, there'll be a new xinetd-2.3.12 RPM in 
RawHide with the one-character fix needed to make this work.