Bug 1006443

Summary:	rpcbind won't start if domainname is set
Product:	[Fedora] Fedora	Reporter:	Ian Collier <imc>
Component:	rpcbind	Assignee:	Steve Dickson <steved>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	hawk, steved
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-23 18:16:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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...