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:
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] 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)?
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: 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
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 (=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.