Bug 18915 - chkconfig doesn't read /etc/xinetd.conf
Summary: chkconfig doesn't read /etc/xinetd.conf
Alias: None
Product: Fedora
Classification: Fedora
Component: chkconfig   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Lukáš Nykrýn
QA Contact: Kevin Baker
Keywords: FutureFeature, Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-11 19:50 UTC by Jonny Robertson
Modified: 2014-12-01 23:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-20 17:53:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 863560 None None None Never

Internal Trackers: 863560

Description Jonny Robertson 2000-10-11 19:50:57 UTC
if you have disabled services is xinetd.conf (with a disabled line),
the services have definately been disabled. (checked this with a netstat).
but when you run a chkconfig --list from the command line, it lists 
services as
being disabled _only_ if a 'disable' line is actually inside 
the /etc/xinetd.d/xxxxxx individual file itself.

or maybe this is a problem with xinetd in that you can turn the services 
off in multiple places?

new zealand

Comment 1 chrismcc 2000-10-16 03:15:50 UTC
I thought I would tack this on here as apposed to opening another bug report...
This seems to be cosmetic only.

[chrismcc@wednesday chrismcc]$ chkconfig --list
xinetd based services:
	amandaidx:	off
	amidxtape:	off
	finger:	off
	linuxconf-web:	off
	ntalk:	off
	talk:	off
	telnet:	off
	tftp:	off
	wu-ftpd:	on
	cvs:	off
	amandaidx.rpmnew:	off
	amidxtape.rpmnew:	off
	swat:	off
	imap:	on
	imaps:	on
	ipop2:	off
	ipop3:	on
	pop3s:	on

service.rpmnew gets listed and can even be manipulated
I checked, and xinetd will ignore config files ending in:
so there is no risk of accidently running these services

Comment 2 Bill Nottingham 2000-10-16 16:48:01 UTC
Correct; chkconfig doesn't read xinetd.conf at all.

Comment 3 Bill Nottingham 2000-10-19 06:44:16 UTC
.rpmnew ignoring will be added in chkconfig-1.2.17-1.

Comment 4 Henri Schlereth 2001-01-17 19:06:06 UTC
Apparently fixed as of chkconfig-1.2.17-1 (RAWHIDE). If this is not the case please re-open this ticket.

Comment 5 Henri Schlereth 2001-01-17 19:07:19 UTC
Sorry, should have added that I manually enabled telnet/restarted xinetd and ran checkconfig to verify that it sees it as being on.

Comment 6 Jonny Robertson 2001-01-17 23:54:13 UTC
just tried upgrading to chkconfig-1.2.17-1 (RAWHIDE), and checked for the
bug i initially reported....

Still seems to be there. :((

If you tell a service in /etc/xinetd.d/ (e.g. telnet) 'disable = no', but
then say 'disable = telnet' in /etc/xinetd.conf:
it still says 'telnet: on' when you do a chkconfig --list.
But telnet _hasn't_ been started because xinetd looks at the xinetd.conf
file as well as the /etc/xinetd.d/* files and realises it needs to be

So chkconfig isn't checking this properly.


Comment 7 Daniel Roesen 2005-06-04 22:13:44 UTC
Jonny, is this still an issue in today's chkconfig?
If not, Bill: will chkconfig be enhanced to read xinetd.conf too?

Comment 8 Bill Nottingham 2005-06-06 05:44:18 UTC
I can answer the first one: the code hasn't changed.

It may be enhanced at some point in the future; barring patches appearing
elsewhere, it probably won't be too soon.

Comment 9 Red Hat Bugzilla 2007-02-05 19:31:40 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 11 Fedora Admin XMLRPC Client 2012-10-18 20:01:33 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Lukáš Nykrýn 2013-02-20 17:53:01 UTC
Disabled in xinetd.conf should be used only as manual and temporary, so I don't think that chkconfig should parse and edit it. Closing this as wontfix.

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