Bug 19957 - wu-ftpd server runs even when `disable = yes' keywords present in xinetd.d entry
Summary: wu-ftpd server runs even when `disable = yes' keywords present in xinetd.d entry
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-28 17:10 UTC by theenglishman
Modified: 2007-03-27 03:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-15 18:49:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description theenglishman 2000-10-28 17:10:03 UTC
The wu-ftpd server still runs when an ftp request is made, even although
the file /etc/xinetd.d/wu-ftpd has the following line:

disable = yes

which is placed in /etc/xinetd.d/wu-ftpd by disabling wu-ftpd using the
"setup" tool.
 Even if xinetd is sent a -HUP signal, wu-ftpd continues to respond to ftp

This happens if the ftp connection is from localhost or from a remote

 My system is a clean install RH7 on a i686, with some services shutdown
(sendmail, nfs etc).

Comment 1 Trond Eivind Glomsrxd 2000-10-30 03:40:53 UTC
So you changed this setting, and it continued to respond? (not the same as
"respond if disable=yes")

Comment 2 theenglishman 2000-10-30 10:00:16 UTC
I changed the line manually to disable = no and it responds to ftp requests - as
Maybe I'm reading man xinetd.conf wrong, but as far as I can see, disable = yes
should override anything else and shut the service down.

 Maybe tcpserver from http://cr.yp.to/ should be included with RH7.1?

Comment 3 Rob Braun 2000-11-15 18:05:14 UTC
My interpretation of this is that you've modified the
config file, kill -HUP'd xinetd, and your changes have
not taken effect.  

If this is in fact the case, it should not work.  As
documented in the xinetd man page, a SIGHUP has xinetd
dump it's debugging information.  What you want is a
SIGUSR2 to reconfigure xinetd.

Comment 4 Trond Eivind Glomsrxd 2000-11-15 18:49:15 UTC
That's what's used in "service xinetd reload".

Comment 5 theenglishman 2000-11-16 09:11:05 UTC
Mmmm. OK, seems a bit wierd not to use a SIGHUP for reconfig, but I guess I
should have RTFM'd a bit more.
Guess this is resolved then - changing to not a bug.

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