Bug 60929 - initscript don't kill a running IPv4 one while starting the IPv6 enabled one
initscript don't kill a running IPv4 one while starting the IPv6 enabled one
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-03-09 08:56 EST by Peter Bieringer
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-04 15:52:01 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 Peter Bieringer 2002-03-09 08:56:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.17-0.13 i686)

Description of problem:
Starting from an IPv4 only box, I've enabled (without rebooting or init 1->3)
IPv6 by loading module and setting value in /etc/sysconfig/network. After some
changes in the xinetd.d config dir I've restarted xinetd. Because of the missing
"kill all xinetd" script would stop the already IPv6 enabled one (isn't still
running) while not touching the already running IPv4 one.

Version-Release number of selected component (if applicable):

How reproducible:
Always, if using described scenario

Steps to Reproduce:
1. Start box without NETWORKING_IPV6 and a running xinetd
3. service xinetd restart

Expected Results:  "restart" should look also for still running IPv4 only
version, "reload" should perhaps check which version is already running

Additional info:

# service xinetd restart
Stopping xinetd-ipv6:                                      [FAILED]
Starting xinetd-ipv6:                                      [  OK  ]
Comment 1 Trond Eivind Glomsrxd 2002-07-24 19:01:51 EDT
Hmm... either need to kill both, or drop the second binary - more IPv6 can be
had without separate binaries now.
Comment 2 Peter Bieringer 2002-10-04 15:51:54 EDT
Happen also in RHL 8.0 but looks like an update to 2.3.8 or upper will solve
this issue completly:


Now ignores the --with-inet6 compile option. Services will default to IPv4
unless configured otherwise.
Comment 3 Peter Bieringer 2002-10-16 16:45:47 EDT
Since last xinetd-errata (update to 2.3.9) this issue is automagically fixed.
xinetd and xinetd-ipv6 are now the same binary.

Enabling a service for IPv6 now needs an explicit flag in service specification:
  flags = IPv6

Pls. remove support of xinet-ipv6 in initscript and also from RPM packaging.

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