Description of problem: having upgraded xinetd to version 2.3.12-0.3E the xinetd daemon hangs after reinitializations (kill -USR2 <pid>) in a syscall futex(0x31a6a0, FUTEX_WAIT, -28, NULL <unfinished ...> and stops to do anything, particularly accepting any connections ... This happens on i686, x86_64 and ia64 architecture. Version 2.3.11-2.3E.0 didn't have that problem. strace during kill -USR2: select(12, [3 6 8 9 10 11], NULL, NULL, NULL) = 1 (in [8]) ### now comes the signal accept(8, {sa_family=AF_INET, sin_port=htons(860), sin_addr=inet_addr("172.31.96.155")}, [16]) = 5 time(NULL) = 1061814351 futex(0x401c36a0, FUTEX_WAIT, -1, NULL and that's it. Version-Release number of selected component (if applicable): 2.3.11-2.3E.0 How reproducible: Steps to Reproduce: 1. kill -USR2 <pid-of-xinetd> Actual results: daemon hangs Expected results: daemon rereads configuration and continues to service Additional info: 2.3.11-2.3E.0 didn't have that problem. We only have SMP-Systems, probably it does not happen on single processors
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.