Red Hat Bugzilla – Bug 197341
xinetd fails to start services when NIS is used
Last modified: 2007-12-03 11:27:15 EST
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.
On every reboot with xinetd enabled;
or manually run :xinetd -d several times
Steps to Reproduce:
1.Configure host as a NIS client:
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 (?).
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?
Created attachment 131950 [details]
. on line 1925, a bind with TCP/993
Next lines shows that it is a request for the passwd map,
NIS server is 22.214.171.124.
. 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)?
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.
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).
(Sorry Ulrich, I have added you to CC list by error.)
As a possible workaround, put:
in /etc/sysconfig/network, so that ypbind is launched with arg "-p 833".
I have found that trick by Googling, at:
Can somebody update the status of this bug. It seems stalled.
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 (=firstname.lastname@example.org):
>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.