Bug 60049
Summary: | temporary disabled services can not be reenabled if a 'redirect' service is running | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Zenon Mousmoulas <zmousm> | ||||
Component: | xinetd | Assignee: | Jay Fenlason <fenlason> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 1.0 | CC: | jfeeney | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-04-10 15:23:22 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Zenon Mousmoulas
2002-02-19 13:50:01 UTC
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> 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. 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. How about 2.3.5, available from http://people.redhat.com/teg/xinetd/ ? 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> 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 mess. 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. 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. 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: /etc/xinetd.conf 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. 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.
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 |