Bug 60049 - temporary disabled services can not be reenabled if a 'redirect' service is running
temporary disabled services can not be reenabled if a 'redirect' service is r...
Product: Red Hat Raw Hide
Classification: Retired
Component: xinetd (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-02-19 08:50 EST by Zenon Mousmoulas
Modified: 2014-08-31 19:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-10 11:23:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
configuration files for xinetd (2.99 KB, application/x-gzip-compressed)
2003-05-14 20:19 EDT, Zenon Mousmoulas
no flags Details

  None (edit)
Description Zenon Mousmoulas 2002-02-19 08:50:01 EST
The following has been noticed on 3 machines running:
RHL6.2 kernel-2.2.19-6.2.12 (errata) xinetd-2.3.3-1.rh6.2
(my own build, using xinetd-2.3.3-1.src.rpm as base, only with minor 
modifications in prereq in order to make it install)
RHL7.1 kernel 2.4.17 (custom build) xinetd-2.3.3-1 (errata)
RHL7.2 kernel-2.4.9-21 (errata) xinetd-2.3.3-1

On all three, I run (at least) these two xinetd services:
proftpd 1.2.5rc1
a redirect service that forwards from a port on eth0 to another on localhost

Both services have "bind = <ip address of eth0>"
Proftpd obeys the global "cps = 5 10" directive.
The redirect service has a "cps = 5 5" setting of its' own.
The redirect service is required in order to provide tcp wrapper ACLs for the 
target daemon (listening on localhost) that doesn't provide such facilities.
Proftpd runs with "user = root".
The redirect service runs as a non-privileged user.

What I noticed is this:
The proftpd service gets disabled due to excessive incoming connections. After 
10 seconds, xinetd tries to reenable it, but it logs

Feb 19 12:29:42 frixos xinetd[581]: Deactivating service proftpd due to 
excessive incoming connections.  Restarting in 10 seconds.
Feb 19 12:29:47 frixos xinetd[581]: bind failed (Address already in use (errno 
= 98)). service = proftpd
Feb 19 12:29:47 frixos xinetd[581]: Error activating service proftpd

From that point on, the connection to the proftpd service port (21) is not 
refused; the socket is opened, but the server doesn't seem to be running, 
because no login prompt or anything else ever comes up.

Next, I tried to manually reload xinetd configuration a little later, hoping 
this bind failure was only a temporary problem caused by xinetd's children not 
having closed some sockets yet in these 10 seconds.
Unfortunately, I get the same "bind failed" error as above with the same 

The only way to solve this is to restart xinetd, effectively killing all 
running instances of both the redirect and proftpd (any any other) services.

It was easy for me to reproduce this problem: since tcp wrappers are used, I 
only have to trigger a flood of connections from an IP address not allowed to 
connect to the proftpd service. So this will do:

# i=1 ; while [ $i -le 15 ] ; do telnet -b <notallowedip> <targethost> 21 ; 
((i++)) ; done

(connection is closed after it is denied by libwrap, so a new telnet starts 
almost immediately, resulting in excessive incoming connections)

I reproduced this situation (after restarting xinetd). This time, when the 
service couldn't be reenabled, I noticed this:

# netstat -lpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name
tcp        0      0 frixos.csl.lab.me:ftp *:*                     LISTEN      

# ps ww -p 17024 -o pid,user,command
17024 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid

This is a child of xinetd, and it should be listening on the redirect port, 
not the ftp port.

# fuser -v -u -n tcp 21

                     USER        PID ACCESS COMMAND
21/tcp               root      17024 f....  xinetd
                     root      17025 f....  xinetd
                     root      17028 f....  xinetd
                     root      17030 f....  xinetd

# ps ww -p 17024,17025,17028,17030 -o pid,user,command
17024 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17025 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17028 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17030 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid

These processes should belong to the redirect service. I don't know why they 
are reported to use this port; fuser says they run as root, ps says they run 
as nobody.

Then I thought maybe this bind failure error happens because both services use 
the 'bind' directive. I removed it and reproduced the situation that caused 
the problem, with the same results though.

Finally, I disabled the redirect service, restarted xinetd, and tried again. 
This time there was no problem: xinetd reenabled the proftpd service after 10 
seconds without errors. However, even after I enabled the redirect service, I 
noticed the problem would still not happen, as long as no redirect service was 
After that I also tested with other service combinations, apart from proftpd. 
AFAIK, any xinetd service with socket_type = stream, protocol = tcp, wait = 
no, together with a tcp redirect service will produce results.

So I am almost certain this is a xinetd issue.
After all this tiresome reading, the question is: is anyone aware of this 
problem? I don't know if it has been fixed in rawhide, but I can't afford the 
multiple xinetd restarts it will take in order to test it, at least not before 
asking you guys first :)
Comment 1 Zenon Mousmoulas 2002-02-20 19:52:27 EST
I tried xinetd-2.3.4-1.4 yesterday. Not only doesn't it fix this problem, but 
it seemed like the redirect attribute is ignored if there is no server 
attribute within the same service config block. Of course, providing a server 
attribute as a workaround to this config parser error causes all sorts of 
other problems.
I have notified Rob Braun <bbraun@synack.net> about the above, and he released 
xinetd-2002.02.20 (http://www.xinetd.org/pub/xinetd/devel/xinetd-
2002.02.20.tar.gz) earlier today, which hopefully fixes redirect being 
ignored. I hope it also fixes the problem initially reported in this bug.
I will try it later and report back here.

On another note, maybe this bug should be listed under Red Hat Rawhide from 
now on.
Comment 2 Zenon Mousmoulas 2002-02-20 21:01:36 EST
Nope, 2002-02-20 still doesn't work. It doesn't ignore config blocks with 
redirect attribute anymore (without server attrib), but a redirect service 
still insists it can't forward the connection to the remote host (while xinetd 
2.3.3 can).
Notified Rob Braun, awaiting further information.
Comment 3 Trond Eivind Glomsrxd 2002-07-08 19:16:34 EDT
How about 2.3.5, available from http://people.redhat.com/teg/xinetd/ ?
Comment 4 Zenon Mousmoulas 2002-12-03 19:30:35 EST
Nope. The redirect facility is still broken under the conditions described in 
this bug, this is true for every xinetd rpm Red Hat has released (RHL, RawHide 
or errata packages) until now every since I created that bug.
It is a problem in xinetd. You can't actually even do a proper config reload 
for xinetd if there is any process running for a redirect service. The 
redirect service processes get killed (SIGKILL) and the service stops 
functioning until xinetd is restarted.
I have written quite a number of times about this to Rob Braun 
<bbraun@synack.net> but he always claims he can't reproduce it or he seems to 
ignore me.

It's really hopeless. Redirect should be either fixed or in my opinion Red Hat 
folks should patch xinetd to completely remove it. This has become such a big 

By the way I don't know if it's related or not, but it seems in the current 
2.3.7-4.7x errata rpm xinetd totally ignores redirect! Please see Bug #78903.
Comment 5 Zenon Mousmoulas 2003-05-13 15:03:55 EDT
I just tried the errata released earlier today, xinetd-2.3.11-1.8.0.i386.rpm 
for RHL 8.0, which indeed takes care another problem with redirect (redirect 
not working at all, as reported in bug #78903), but the long-living problem I 
have reported here is still there.
If something causes a service to be temporary disabled, and there's at least 1 
redirect service enabled at the time, the first service will never be re-
enabled unless xinetd is restarted.
Comment 6 Jay Fenlason 2003-05-14 17:27:22 EDT
Hmm.  I wasn't able to reproduce this on my Red Hat Linux 8.0 box.  Can you
append to this bug report a copy of the following from a broken system?  You may
want to create a tar file of the files and attach it, rather than attaching
individual files.

I need:
the output of an ls -lf on /etc/xinetd.d
all the files in /etc/xinetd.d

Maybe then I'll be able to reproduce it.
Comment 7 Zenon Mousmoulas 2003-05-14 20:19:29 EDT
Created attachment 91687 [details]
configuration files for xinetd

These configuration files are from a different box, with a slightly different
setup. However the differences are insignificant and the result is exactly the
same as the one described in the initial report.
You should be able to reproduce this behavior if you follow the procedure I
described. In my experience, the specifics of xinetd's configuration are
irrelevant, as long as there is one normal tcp service and one with redirect
enabled. As soon as the normal service is temporarily disabled due to cps
restrictions, if there is at least one instance of the redirect service
running, xinetd will fail to re-enable the first service.
Comment 8 David Lawrence 2006-04-10 11:23:22 EDT
Closing due to inactivity. Please feel free to reopen this bug or refile this
bug against the latest release Fedora Core if you feel this bug is still
relevant today.

Thank you

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