Bug 1006443 - rpcbind won't start if domainname is set
Summary: rpcbind won't start if domainname is set
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpcbind
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-10 15:50 UTC by Ian Collier
Modified: 2014-10-23 18:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-23 18:16:42 UTC
Type: Bug


Attachments (Terms of Use)

Description Ian Collier 2013-09-10 15:50:25 UTC
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 12:18:21 UTC
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 18:16:42 UTC
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.