Red Hat Bugzilla – Bug 79274
Xinetd v 2.3.7-4.7x redirects fail to start
Last modified: 2014-08-31 19:24:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
With xinetd 2.3.7-4.7x the /etc/xinetd.d/ entries that represent local services
start just fine, but the entries that represent redirects do not seem to be
recognised. The output from xinetd -d shos that the files are found and read
with no extra debug output showing an error.
Downgrading to 2.3.3-1 with the same xinfig files in xinetd.d brings the
redirects back into service.
Version-Release number of selected component (if applicable):
An xinetd.d file that works under the old version of xinetd, but not the new one.
[root@zool root]# cd /etc/xinetd.d/
[root@zool xinetd.d]# cat http
# default: off
# description: A port forward for http
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
redirect = 192.168.15.1 80
This is a known bug in v2.3.7 and I just got nailed by it this morning when we
updated xinetd. Redhat really needs to fix this - all port redirects seem
broken with version 2.3.7
where other users report this issue
We have backed down to v2.3.4 and everything with our redirects is working again
A fix was formally released in 2.3.8
* Reworked redirect to better detect problems
in its configuration. Also, redirect now allows
service names for port numbers. -Steve Grubb
... and there is now a 2.3.9 (Released 24 Sep 2002)
This one will quite probably hurt Red Hat's corporate customers who are trying
to use RH7.2/7.3/8.0 as a proxy-firewall platform. It really isn't making Red
Hat's QA function look that good.
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.