Bug 15002 - Multiple xinetd entries in "Control service activity"
Summary: Multiple xinetd entries in "Control service activity"
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: linuxconf   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-01 17:15 UTC by Dean Pentcheff
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-01 17:15:39 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 Dean Pentcheff 2000-08-01 17:15:37 UTC
The "xinetd" entry in the "Control service activity" module appears twice
at the end of the listing.  (I am not sure if this is specific to xinetd or
to whichever is the last item in the listing in linuxconf.)

I get the impression that an attempt has been made to merge the (x)inetd
and /etc/rc.d services into the single "Control service activity" module of
linuxconf.  In the double-listing of xinetd, one listing has the
appropriate "runlevels" checked off (appropriate for an /etc/rc.d-style
service), and one listing has all runlevels unselected (as though it were a
(x)inetd-style service).

Suspicion and recommendation: The integration of (x)inetd-style and
/etc/rc.d-style services into a single panel is ill-conceived, since they
have considerably different properties.  (x)inetd-style services have
type/protocol/path/argument properties; while /etc/rc.d-style services have
runlevels and running-status.  In the current (beta) setup, it seems as
though we can set runlevels for (x)inetd services, and we lose the ability
to configure the other properties.  The previous separation into two
linuxconf modules (Config->Networking->ServerTasks->BasicServices->Servers
for /etc/rc.d services and Control->ControlServiceActivity for inetd
services) gave a much clearer way to control their properties.  I also
suspect that the double-listing of xinetd in the current rev is a
side-effect of amalgamating these into one panel.  I'd recommend dropping
back to the earlier separation into two linuxconf modules.

Comment 1 Nalin Dahyabhai 2000-08-02 22:51:59 UTC
The naming collision is resolved in the devel tree, where the xinetd service has
been renamed to "linuxconf-web".

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