Bug 914792

Summary:	LOCKD_TCPPORT and LOCKD_UDPPORT not working and inconsistent
Product:	[Fedora] Fedora	Reporter:	Colin.Simpson
Component:	nfs-utils	Assignee:	Steve Dickson <steved>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	18	CC:	bfields, jlayton, steved
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	nfs-utils-1.2.7-5.fc18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-08 12:52:29 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:
Embargoed:

Description Colin.Simpson 2013-02-22 19:04:27 UTC

Description of problem:

Setting LOCKD_TCPPORT and LOCKD_UDPPORT seem to get ignored at boot time. 

It seems as if nfs-lock is never executed (thereby reading the LOCKD_TCPPORT and LOCKD_UDPPORT values) if only nfs-server is chkconfig'd on, but a nlockmgr is registered as shown by rpcinfo -p (but on random ports). Maybe this is by design but seems strange.

Even if nfs-lock and nfs-server are both chkconfig'd on, on boot the nlockmgr is registered as shown by rpcinfo -p on random ports. I have put debug in 
/usr/lib/nfs-utils/scripts/nfs-lock.preconfig and this seems to be setting the kernel parameter so I'm confused. And restart the nfs-server now brings nlockmgr onto the correct ports. 


Version-Release number of selected component (if applicable):

All I've seen F18

nfs-utils-1.2.7-3.fc18

How reproducible:
Every time

Steps to Reproduce:
1. Set LOCKD_TCPPORT and LOCKD_UDPPORT in /etc/sysconfig/nfs
2.Boot the system
3.Run rpcinfo -p and see that nlockmgr is registered on random ports
  
Actual results:
Registers nlockmgr on random ports, unless nfs-server is restarted, then goes correct.


Expected results:
Register nlockmgr on the specified ports

Additional info:

Comment 1 Colin.Simpson 2013-03-22 20:54:13 UTC

I'm finding it hard to debug this one. It's not consistent between systems and I don't know why.

Some things to consider though on this. As a test setup if I chconfig off nfs-server, nfslock and rpcbind and reboots between tests.

If I start the rpcbind service then the wrong random nlockmgr ports always appear, if they have been that way before. This is due to the "rpcbind" "-w" , warm start option that stores the old wrong registrations in /var/lib/rpcbind, so I'm not sure that option is too helpful, well in this case at least.

Next case, if I remove /var/lib/rpcbind/* (with rpcbind down) and start nfs-lock and then nfs-server services, the ports are correct and everything works.

Next case, if I again remove /var/lib/rpcbind/* (with rpcbind down) and start just the nfs-server service, I again get random ports for nfslockmgr in my rpcinfo -p.

Okay, so my working case is nfs-lock and nfs-server chkconfig'd on and blanking the warm start rpcbind cache (remove /var/lib/rpcbind/*). But on reboot this still doesn't work for me, the ports come up random.

So I thought okay, so I added nfs-lock.service to the "After=" line of nfs-server, and this works and forces the correct port registration (assuming you blanked the the rpcbind warm start cache). Now I know this is far from ideal as you maybe pure NFSv4 and not need nfs-lock.

Maybe the nfs-lock service should be eliminated and nfs-server should start nfs-lock if NFSv3 is detected as still being used?

I'd hate this bug to make it all the way to RHEL7.

Comment 2 J. Bruce Fields 2013-03-22 21:12:06 UTC

I've never looked at those two port settings before....  Where are they even being used?

Grepping around. Ah-hah, it looks like /usr/lib/scripts/nfs-utils/nfs-lock.preconfig sources /etc/sysconfig/nfs and then sets the ports.

So, yes, it makes sense that you'd need nfs-lock started first.

NFSv4-only setups aren't really well supported right now; e.g. even if userspace does everything right I believe the kernel will still start up lockd service whenever nfsd is, even in the absence of v2/v3.

Comment 3 Colin.Simpson 2013-03-22 21:15:56 UTC

So do you plan to add the nfs-lock service to the After line in nfs-server or do you have another idea?

Comment 4 J. Bruce Fields 2013-03-22 21:29:21 UTC

For now that sounds like the right thing to do; steved?

Comment 5 Fedora Update System 2013-03-25 16:14:14 UTC

nfs-utils-1.2.7-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.7-4.fc18

Comment 6 Colin.Simpson 2013-03-25 18:06:04 UTC

The update seems to have resolved my issue, and the rpcbind warm start DOESN'T seem to be causing an issue with the old incorrect ports being "sticky". 

Excellent, thanks for the fast response.

Comment 7 Fedora Update System 2013-03-25 22:56:52 UTC

Package nfs-utils-1.2.7-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.7-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4396/nfs-utils-1.2.7-5.fc18
then log in and leave karma (feedback).

Comment 8 Colin.Simpson 2013-07-19 23:33:51 UTC

This seems to have regressed in F19, despite the "nfs-lock" service being on the After line in nfs-server. 

I haven't fully investigated but stopping "nfs-server" and "nfs-lock", then starting nfs-lock and nfs-server seems to fix once booted, but this just fails at boot.

Also if booted "init 5" (sorry still old school in my startup terms not so familiar with systemd), then you run "init 3" the nfs services seem to stop. Not ideal.