Bug 15002

Summary: Multiple xinetd entries in "Control service activity"
Product: [Retired] Red Hat Linux Reporter: Dean Pentcheff <dean2>
Component: linuxconfAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0   
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: 2000-08-01 17:15:39 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:

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".