Bug 103009 - xinetd version 2.3.12-0.3E hangs in syscall futex( after reinitializations
Summary: xinetd version 2.3.12-0.3E hangs in syscall futex( after reinitializations
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: xinetd
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 101028
TreeView+ depends on / blocked
 
Reported: 2003-08-25 12:29 UTC by Albert Fluegel
Modified: 2014-08-31 23:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-09-03 02:41:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
xinetd configuration (2.78 KB, application/octet-stream)
2003-08-26 08:17 UTC, Albert Fluegel
no flags Details

Description Albert Fluegel 2003-08-25 12:29:17 UTC
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

Comment 1 Jay Fenlason 2003-08-25 15:25:35 UTC
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? 

Comment 2 Albert Fluegel 2003-08-26 08:17:08 UTC
Created attachment 93929 [details]
xinetd configuration

Requested by redhat bugzilla xinetd maintainer

Comment 3 Albert Fluegel 2003-08-26 08:40:18 UTC
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.


Comment 4 Jay Fenlason 2003-09-03 02:41:53 UTC
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. 


Note You need to log in before you can comment on or make changes to this bug.