Red Hat Bugzilla – Bug 112598
/etc/init.d/nfs does not respect LOCKD_TCPPORT & LOCKD_UDPPORT
Last modified: 2007-11-30 17:10:34 EST
Description of problem:
setting LOCKD_TCPPORT & LOCKD_UDPPORT in /etc/sysconfig/nfs have no
effect on reboot (but work with service nfs restart)
Version-Release number of selected component (if applicable):
always on boot
(run rpcinfo -p to confirm that nlockmgr is using random ports)
Steps to Reproduce:
nlockmgr uses random high ports after boot but uses the correct ports
after service nfs restart
nlockmgr uses the ports specified in /etc/sysconfig/nfs
Created attachment 96688 [details]
patch for /etc/init.d/nfs
- the main problem is that the sysctl -w fs.nfs.nlm_tcpport (& udpport) fails
with "unknown key" when booting. Moving the call to exportfs before the sysctl
fixes this. It works ok with service nfs restart.
- the tests like [ -n "LOCKD_TCPPORT ] should be [ -n "$LOCKD_TCPPORT ] but I
believe these are harmless here.
Created attachment 100631 [details]
Fix that starts and stops nfsd once if necessary to create the needed parameter keys
With Fedora Core 2 I see the same behaviour (LOCKD_TCPPORT and LOCKD_UDPPORT
have no effect) although Kevin's fix has been integrated into /etc/init.d/nfs.
Even though exportfs is called before trying to set those values via sysctl,
the two calls fail with the well-known message about using an "unknown key", as
Playing around, it seems that the keys fs.nfs.* are available when the kernel
nfsd has been started at least once, which is done some lines after trying to
set the values in the init script.
--> Fix (that works at least for me):
Start and stop the kernel nfsd once before setting the TCP and UDP ports in
/etc/init.d/nfs (see attached diff).