NFS Performance Tuning for HP-UX 11.0 and 11i Systems

nfs performance tuning for hp-ux 11.0 and 11i systems page 65

Notes:

Page 65July 22, 2002

rpc.lockd

rpc.statd

Troubleshooting rpc.lockd & rpc.statd

• Use rpcinfo(1M) command to “ping” lockd & statd

• Collect debug-level rpc.lockd and rpc.statd

logfiles via the SIGUSR2 toggle mechanism

• Collect a set of network traces on both the NFS

client and server while the file locking problem is

reproduced

One of the quickest and most non-intrusive methods of determining whether the

lockd and statd processes are responding is to use the rpcinfo(1M) command to

“ping” the running daemons. Since both client’s and server’s lockd and statd

daemons are used during NFS file locking, the recommendation is to test the

server’s lockd and statd from the client system and vice versa.

Among the best sources of information for troubleshooting NFS file locking

problems are debug lockd and statd logfiles collected while reproducing the

failure. Debug logging can be toggled on and off by sending the SIGUSR2 signal

to the running lockd or statd process (i.e. kill –17 <pid>). By default, the debug

information is logged to the /var/adm/rpc.lockd.log and

/var/adm/rpc.statd.log files respectively.

In some cases, a network trace is also needed to fully understand the root cause of

an NFS file locking problem. Since the problem could be that the server is not

sending replies at all or is sending the replies to the wrong system/port number, it

is important to collect network traces on both the client and server to determine

whether the lock requests and replies are traversing the network successfully.