Bug 15002 - Multiple xinetd entries in "Control service activity"
Multiple xinetd entries in "Control service activity"
Product: Red Hat Linux
Classification: Retired
Component: linuxconf (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2000-08-01 13:15 EDT by Dean Pentcheff
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-01 13:15:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dean Pentcheff 2000-08-01 13:15:37 EDT
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 18:51:59 EDT
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.