Bug 60929

Summary:	initscript don't kill a running IPv4 one while starting the IPv6 enabled one
Product:	[Retired] Red Hat Linux	Reporter:	Peter Bieringer <pb>
Component:	xinetd	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED ERRATA	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-10-04 19:52:01 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 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.