Bug 197341

Summary: xinetd fails to start services when NIS is used
Product: [Fedora] Fedora Reporter: Jacques Beigbeder <jacques.beigbeder>
Component: xinetdAssignee: Jan Safranek <jsafrane>
Status: CLOSED UPSTREAM QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fenlason, laurent.rineau__fedora
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: 2007-12-03 16:27:15 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:
Attachments:
Description Flags
Requested trace. none

Description Jacques Beigbeder 2006-06-30 12:05:57 UTC 
Description of problem:
Using NIS, on boot, xinetd fails to start services with (syslog output):
bind failed (Address already in use (errno = 98)). service = imaps
Some problem on services : pop3s, shell, login.

Version-Release number of selected component (if applicable):
FC5, last updates on 06/30/2006.

How reproducible:
On every reboot with xinetd enabled;
or manually run :xinetd -d several times

Steps to Reproduce:
1.Configure host as a NIS client:
  passwd:     compat
  shadow:     compat
  group:      files nis
  hosts: files dns
  netgroup: files nis
2. Run : tcpdump tcp and port 993
3. Run: 'xinetd -d' and Control-C, several times.

Sometimes, xinetd fails on imaps (993) and then tcpdump displays traffic
with the NIS server.
It seems that NIS requests leaves opened sockets, and then xinetd
fails to bind on the wanted socket.

Fix 1: NIS requests should close any socket before returns. (?)
Fix 2: kernel improperly fails on just closed sockets (?).

Actual results:


Expected results:


Additional info:
Comment 1 Jay Fenlason 2006-06-30 18:30:31 UTC 
I don't think it's xinetd's fault if it can't bind to a specified port because 
another application is already using it.  Perhaps you can tell your rpc 
subsystem to not use those ports? 
 
Can you get me an strace of the failing xinetd?
Comment 2 Jacques Beigbeder 2006-07-05 17:39:34 UTC 
Created attachment 131950 [details]
Requested trace.

. on line 1925, a bind with TCP/993
  Next lines shows that it is a request for the passwd map,
  NIS server is 129.199.96.15.

. line 1960 closes the file descriptor 9.

. line 4871 is the failing bind.
  And on line 4877:
		Service imaps failed to start and is deactivated

A tcpdump (tcpdump -X port 993 and tcp) shows that the traffic
is really the query of this NIS map. So I think the problem
is not in another process but in xinetd, or in the kernel
(which fails to close last used sockets)?
Comment 3 Jay Fenlason 2006-07-05 18:10:41 UTC 
Ok.  Here's what's happening.  The nss module is picking a "random" low 
numbered port to contact the NIS server, and it happens to pick the port that 
the IMAPS service needs.  Because of the required delay between uses of the 
same socket number, xinetd cannot then bind to that socket.  That's not an 
xinetd problem, it's just the way TCP works.  What we need is a way to tell 
the nss module to not use that port.  I'm reassigning this bug to the owner of 
the nss module.
Comment 4 Ulrich Drepper 2006-07-26 16:36:47 UTC 
There are no unused ports in general, these conflicts cannot be avoided.  xinetd
simply has to be more tolerant.  If the socket is not yet usable it should try
again later (probably in the background).
Comment 5 Laurent Rineau 2007-01-10 16:26:45 UTC 
(Sorry Ulrich, I have added you to CC list by error.)

As a possible workaround, put:
  OTHER_YPBIND_OPTS="-p 833"
in /etc/sysconfig/network, so that ypbind is launched with arg "-p 833".

I have found that trick by Googling, at: 
http://www.redhat.com/archives/taroon-list/2004-September/msg00233.html
Comment 6 Laurent Rineau 2007-11-12 12:28:27 UTC 
Can somebody update the status of this bug. It seems stalled.
Comment 7 Jan Safranek 2007-12-03 16:27:15 UTC 
The bug has been really low on my todo list, sorry for not updating it for so
long. I finally got a response from upstream (=bbraun):

>will look at implementing this, but it won't be within the next few weeks.

I close it as UPSTREAM. Xinetd does not have any bug tracker, you have to trust me.