Bug 249121 - "rpcbind: cannot bind * on udp" in a startup
Summary: "rpcbind: cannot bind * on udp" in a startup
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpcbind
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F8Blocker
TreeView+ depends on / blocked
 
Reported: 2007-07-21 01:05 UTC by Michal Jaegermann
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-18 17:01:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2007-07-21 01:05:33 UTC
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 23:13:58 UTC
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 19:52:08 UTC
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 13:18:08 UTC
what does you /etc/netconfig look like? are the udp/tcp definitions
before the udp6/tcp6?

Comment 4 Michal Jaegermann 2007-09-24 19:18:28 UTC
> 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 19:41:29 UTC
Shows up with qemu with only one net device, so not likely to be multiple
interfaces.

Comment 6 Jeremy Katz 2007-10-11 20:29:47 UTC
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 22:16:58 UTC
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 19:56:43 UTC
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 14:59:54 UTC
Fixed in libtirpc-0.1.7-11.fc8

Comment 10 Will Woods 2007-10-18 17:01:39 UTC
Confirmed fixed in today's rawhide. 


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