Bug 103009 - xinetd version 2.3.12-0.3E hangs in syscall futex( after reinitializations
xinetd version 2.3.12-0.3E hangs in syscall futex( after reinitializations
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: xinetd (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
:
Depends On:
Blocks: 101028
  Show dependency treegraph
 
Reported: 2003-08-25 08:29 EDT by Albert Fluegel
Modified: 2014-08-31 19:25 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-02 22:41:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Albert Fluegel 2003-08-25 08:29:17 EDT
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 11:25:35 EDT
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 04:17:08 EDT
Created attachment 93929 [details]
xinetd configuration

Requested by redhat bugzilla xinetd maintainer
Comment 3 Albert Fluegel 2003-08-26 04:40:18 EDT
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-02 22:41:53 EDT
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.