This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1006443 - rpcbind won't start if domainname is set
rpcbind won't start if domainname is set
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-10 11:50 EDT by Ian Collier
Modified: 2014-10-23 14:16 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-23 14:16:42 EDT
Type: Bug
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 Ian Collier 2013-09-10 11:50:25 EDT
Starting from single-user mode, if I set the nis domain before starting rpcbind then it will not start properly:

# domainname x
# systemctl start rpcbind.service
# rpcinfo -p
** wait 60 seconds **
rpcinfo: can't contact portmapper: RPC: Timed out

This is a problem because there is a race condition in the startup sequence when both rpcbind and ypbind are enabled.  If I do:

# systemctl start rpcbind.service; systemctl start ypbind.service

then after a delay it tells me it could not start ypbind (and in addition, rpcinfo does not work either).  However, if I do:

# systemctl start rpcbind.service; sleep 1; systemctl start ypbind.service

then both services start OK.  Unfortunately, every time I boot up the machine with both rpcbind and ypbind enabled, the race condition hits and subsequently I cannot log into the machine at all (even as local root).

This problem occurs with rpcbind-0.2.1-0.fc19.x86_64.  It did not occur with rpcbind-0.2.0-21.fc19.x86_64 - that release starts up properly even if the domain name is set.
Comment 1 Richard Neuboeck 2013-09-23 08:18:21 EDT
I can confirm the problem with rpcbind-0.2.1-0.fc19.x86_64 and the solution to unset the domainname right before executing rpcbind.

However modifying the systemd service file accordingly doesn't solve the problem entirely though. As mentioned by Ian there seems to be a race condition between rpcbind.service and ypbind.service.

That's why there is this 'ExecStartPost=/usr/bin/sleep 5' statement in the modified service file below. Removing this causes rpcbind to stall (a long time, in my case about 25min) and ypbind (and subsequent services) to fail entirely.

A crude manual fix for now is to create /etc/systemd/system/rpcbind.service containing the following:


.include /usr/lib/systemd/system/rpcbind.service
[Service]
EnvironmentFile=/etc/sysconfig/network
ExecStartPre=/usr/bin/domainname ''
ExecStartPost=/usr/bin/sleep 5
Comment 2 Steve Dickson 2014-10-23 14:16:42 EDT
Well it appears ypbind.service is cause the rpcbind to be
started first 

Description=NIS/YP (Network Information Service) Clients to NIS Domain Binder
Requires=rpcbind.service
After=syslog.target network-online.target rpcbind.service ypserv.service NetworkManager-wait-online.service
Before=systemd-user-sessions.service

(In reply to Ian Collier from comment #0)
> Starting from single-user mode, if I set the nis domain before starting
> rpcbind then it will not start properly:
> 
> # domainname x
> # systemctl start rpcbind.service
> # rpcinfo -p
> ** wait 60 seconds **
> rpcinfo: can't contact portmapper: RPC: Timed out
I'm unable to reproduce this with fedora 20 or 21 

The timed out does make sense though, if rpcinfo is try to
resolve a hostname and there is an invalid domain name
that lookup would time out...

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