Bug 236514 - rpcbind won't start on bootup
rpcbind won't start on bootup
Status: CLOSED DUPLICATE of bug 236639
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-15 15:41 EDT by Saikat Guha
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-17 09:11:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saikat Guha 2007-04-15 15:41:15 EDT
rpcbind doesn't start up, freezes during init.
Manually skipping all rpc services allows bootup.
Starting rpcbind manually after booting up freezes rpcbind

Problem seems to be that the AF_INET socket that rpcbind ends up
binding to is on a *random* port instead of the 111 portmapper
port. Later when rpcbind itself attempts to send a packet, it sends
it to port 111 which is not open.

Adding rpcbind to /etc/services as an alias of 111 fixes the problem
  sunrpc          111/tcp         portmapper rpcbind      # RPC 4.0 portmapper TCP
  sunrpc          111/udp         portmapper rpcbind      # RPC 4.0 portmapper UDP

Looking through the rpcbind code, it appears rpcbind is supposed to fallback to
using the portmapper port if it can't one in /etc/services for rpcbind.

Line 116: static char servname[] = "rpcbind";
Line 385: if ((aicode = getaddrinfo(hosts[nhostsbak],
                servname, &hints, &res)) != 0) {
              if ((aicode = getaddrinfo(hosts[nhostsbak],
                            "portmapper", &hints, &res)) != 0) {


However, it would appear that getaddrinfo is returning a 0 return value even
when it couldn't find a port for "rpcbind" in /etc/services. According to the
man page for getaddrinfo, it should return -1 with errno set to EAI_SERVICE or
EAI_NONAME when the service cannot be found.

Is this a glibc bug? Or is it a rpcbind bug?

Also, rpcbind should probably be listed explicitly in /etc/services which is
owned by the setup package.



Possible resolutions:
1. Add rpcbind to the port 111 line in /etc/services
2a. Fix getaddrinfo to return -1 when the service is not found; if that is not
considered a bug,
2b. Fix rpcbind to detect if getaddrinfo failed to find a suitable port some
other way.
Comment 1 Steve Dickson 2007-04-17 09:11:26 EDT

*** This bug has been marked as a duplicate of 236639 ***

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