Red Hat Bugzilla – Full Text Bug Listing
|Summary:||"rpcbind: cannot bind * on udp" in a startup|
|Product:||[Fedora] Fedora||Reporter:||Michal Jaegermann <michal>|
|Component:||rpcbind||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-18 13:01:39 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Michal Jaegermann 2007-07-20 21:05:33 EDT
Description of problem: After recent updates a startup looks like that: ..... Bringing up loopback interface: [ OK ] Bringing up interface eth1: Determining IP information for eth1... done. [ OK ] Starting rpcbind: rpcbind: cannot bind * on udp: Address already in use rpcbind: cannot bind tcp: Address already in use [ OK ] Starting NFS statd: [ OK ] Starting auditd: [ OK ] Starting RPC idmapd: [ OK ] Mounting other filesystems: [ OK ] ..... It is very far from clear to me what is responsible for this "cannot bind". 'service rpcbind status' and 'service rpcbind restart' seem to work normally. OTOH 'telinit 1' followed by 'telinit 3' will bring a message like the one quoted above. Looking with 'netstat' one can find rpcbind on one tcp port (111) and two udp ports (111 and some other one which is changing). Expected? Version-Release number of selected component (if applicable): rpcbind-0.1.4-7.fc8 How reproducible: bringing a machine to level 3 from level one does the above every time
Comment 1 David K. Means 2007-08-27 19:13:58 EDT
Additionally, if there is more than one Ethernet interface, specifying which one to bind to (rpcbind -h 192.168.x.y) does not work correctly; instead, netstat -utan --program shows that rpcbind is listening on all interfaces for IPv4 udp packets, and on no IPv4 interfaces for tcp packets. For IPv6, rpcbind is listening on all interfaces (since we have not told it to restrict that protocol).
Comment 2 Jeremy Katz 2007-09-05 15:52:08 EDT
The binds failing are the AF_INET6 binds based on looking at the failure with strace. But nothing else is listening on the ipv6 sockets afaict
Comment 3 Steve Dickson 2007-09-17 09:18:08 EDT
what does you /etc/netconfig look like? are the udp/tcp definitions before the udp6/tcp6?
Comment 4 Michal Jaegermann 2007-09-24 15:18:28 EDT
> what does you /etc/netconfig look like? It is a default one provided, currently, by libtirpc-0.1.7-10.fc8 package. Non-comment lines look like follows: udp tpi_clts v inet udp - - tcp tpi_cots_ord v inet tcp - - udp6 tpi_clts v inet6 udp - - tcp6 tpi_cots_ord v inet6 tcp - - rawip tpi_raw - inet - - - local tpi_cots_ord - loopback - - - unix tpi_cots_ord - loopback - - - Maybe a presence of two network interfaces has something to do with the error message?
Comment 5 Jeremy Katz 2007-09-24 15:41:29 EDT
Shows up with qemu with only one net device, so not likely to be multiple interfaces.
Comment 6 Jeremy Katz 2007-10-11 16:29:47 EDT
Steve -- any progress here (or at least, luck reproducing it)? This is extremely visible to all users after installation and so we should really make sure its fixed
Comment 7 David K. Means 2007-10-11 18:16:58 EDT
After reviewing the comments here, and going back to reproduce this on my systems, I have a couple of additional notes: 1. The problem is visible in rpcbind-0.1.4.6-fc7.i386 2. My /etc/netconfig is identical to the one reported (the default) 3. Following this rpcbind complaint is another: rpcbind: cannot bind tcp6: Address already in use. 4. This system is running on an AMD dual-core processor, and so the SMP stuff is invoked, and these messages are reported in /var/log/messages AFTER both CPU0 and CPU1 are started. Occasionally, the number of intervening kernel messages between the udp6 complaint and the tcp6 complaint varies. Does this maybe indicate a race (due to the multiple CPUs??? [just guessing here; I haven't even tried to look at the code.] 5. My original observation about rpcbind listening for UDP packets on *all* ports, rather than just the one specified (with -h) was incorrect; for IPv4, the binding is made correctly. There is a complaint message in the log, though: rpcbind: cannot have more than one UDP transport in this case.
Comment 8 Steve Dickson 2007-10-12 15:56:43 EDT
Yes I have also been looking into this... It seems rpcbind is binding to INADDR_ANY on a ipv4 socket and a ipv6 socket. Because they sockets have the same port and address, the second set of binds (i.e. udp6 and tcp6) fail. I'm working with upstream to figure out what to do... If by chance I unsuccessful finding a fix we would we could turn off the bind of tcp6 and upd6 socket with the following change to /etc/netconfig: +++ /etc/netconfig 2007-10-12 15:49:19.000000000 -0400 @@ -12,8 +12,8 @@ # udp tpi_clts v inet udp - - tcp tpi_cots_ord v inet tcp - - -udp6 tpi_clts v inet6 udp - - -tcp6 tpi_cots_ord v inet6 tcp - - +udp6 tpi_clts - inet6 udp - - +tcp6 tpi_cots_ord - inet6 tcp - - rawip tpi_raw - inet - - - local tpi_cots_ord - loopback - - - unix tpi_cots_ord - loopback - - which make tcp6/udp6 not visible.
Comment 9 Steve Dickson 2007-10-15 10:59:54 EDT
Fixed in libtirpc-0.1.7-11.fc8
Comment 10 Will Woods 2007-10-18 13:01:39 EDT
Confirmed fixed in today's rawhide.