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:
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.
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.
So do you plan to add the nfs-lock service to the After line in nfs-server or do you have another idea?
For now that sounds like the right thing to do; steved?
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
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.
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).
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.