Red Hat Bugzilla – Bug 60929
initscript don't kill a running IPv4 one while starting the IPv6 enabled one
Last modified: 2007-04-18 12:40:48 EDT
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 ]
Hmm... either need to kill both, or drop the second binary - more IPv6 can be had without separate binaries now.
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.
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.