Bug 1285091 - xinetd attempts to bind to IPv6 sockets even on systems with IPv6 disabled
xinetd attempts to bind to IPv6 sockets even on systems with IPv6 disabled
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xinetd (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jan Synacek
Robin Hack
: EasyFix, Patch
Depends On:
Blocks: 1270825
  Show dependency treegraph
Reported: 2015-11-24 16:15 EST by Karl Hastings
Modified: 2016-05-10 17:42 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-10 17:42:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch (753 bytes, patch)
2015-12-01 10:04 EST, Jan Synacek
no flags Details | Diff

  None (edit)
Description Karl Hastings 2015-11-24 16:15:28 EST
Description of problem:
xinetd attempts to open sockets with PF_INET6 by default, even on systems with IPv6 module disabled ('options ipv6 disabled=1' in /etc/modprobe.d/*)

This causes xinetd to kill long running clients with xinetd is reloaded because xinetd appears to believe the config has changed for the service.

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

How reproducible:

Steps to Reproduce:
1. enable telnet, or some other connection service in xinetd
2. disable IPv6 (blacklist the module, or options ipv6 disabled=1)
3. reboot
4. telnet (or connect to enabled service)
5. send SIGHUP (or 'service xinetd reload')

Actual results:
telnet connection is dropped because the telnet process receives SIGKILL

Expected results:
telnet connection stays up because telnet config didn't change

Additional info:
IPv6 by default was added in https://bugzilla.redhat.com/show_bug.cgi?id=195265

It looks like now if IPv6 is disabled xinetd gets confused thinking the running config doesn't match the defined service and will always send a SIGKILL (would send SIGTERM if the service were type = INTERNAL).  This is not desired behavior as the telnet (or whatever defined service) configuration has not changed.

Clarification was added to the man pages via: https://bugzilla.redhat.com/show_bug.cgi?id=1075152  but that misses the point.  The work-around would be to set 'flags = IPv4' to the service or 'bind =' to the main xinetd.conf   (as documented on our portal: https://access.redhat.com/solutions/706163 )  Maybe that should be added to the man page, as it is more relevant...

However customer feels that xinetd should handle this situation gracefully
Comment 4 Jan Synacek 2015-12-01 10:04 EST
Created attachment 1100938 [details]
Comment 15 errata-xmlrpc 2016-05-10 17:42:13 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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