flock and NFS

[Ric Werme]

> I've always been wary of using flock on NFS. Am I being superstitious?

No.  Especially flock(2), as some Unixes treated that separately from lockf(3)
and fcntl(2).  Flock on those systens only did local locking and didn't call
the file system, with fcntl being the only system interface to the file
system, and hence to NFS locking.  Everyone may now have flock calling file
system code now.  lockf(3) is a libc routine that uses fcntl2().  Confused
yet?  I've always used fcntl.

> The usage scenario I'm thinking of is N nodes trying to acquire a lock
> on file F that is located on the NFS server. How can I determine if
> the proper NFS components are in place in order for the programs to
> function correctly?

The best way to see if something has a chance of working is with rpcinfo, e.g.:

tux:mlb> /usr/sbin/rpcinfo -t localhost nlockmgr
program 100021 version 1 ready and waiting
rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 4
program 100021 version 2 is not available
program 100021 version 3 ready and waiting
program 100021 version 4 ready and waiting

tux:mlb> /usr/sbin/rpcinfo -t localhost status
program 100024 version 1 ready and waiting

The latter test is of a protocol that helps NFS (and could help anyone else)
recover from crashed clients and servers.

You can also test mountd and nfs, but those have to be on a NFS server to do
anything with NFS.  The lock service has to be on both client and server
on some systems.  On a pure Linux system, perhaps only on the server.