Bug 60929 - initscript don't kill a running IPv4 one while starting the IPv6 enabled one
Summary: initscript don't kill a running IPv4 one while starting the IPv6 enabled one
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-09 13:56 UTC by Peter Bieringer
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-10-04 19:52:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Peter Bieringer 2002-03-09 13:56:14 UTC
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
2. Set NETWORKING_IPV6
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 23:01:51 UTC
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 19:51:54 UTC
Happen also in RHL 8.0 but looks like an update to 2.3.8 or upper will solve
this issue completly:

http://www.xinetd.org/#changes

2.3.8
Now ignores the --with-inet6 compile option. Services will default to IPv4
unless configured otherwise.


Comment 3 Peter Bieringer 2002-10-16 20:45:47 UTC
Since last xinetd-errata (update to 2.3.9) this issue is automagically fixed.
xinetd and xinetd-ipv6 are now the same binary.

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


Note2:
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.