Why does rpc.lockd(8) and rpc.stat(8) require a working Internet connection

[Rick Macklem]

Aryeh Friedman wrote:
>My cable modem was out for a few hours last night and my NFS based *LOCAL*
>(same subnet [192.168.11.XXX] and physical LAN) file server started
>glitching up on attempting to contact lockd and statd on the server from
>the client(s) saying that the service was non-responsive and/or the server
>couldn't be found.   I attempted to switch over to /etc/hosts based host
>resolution to no avail.   I also tried switching to purely IP addr based
>connections to no avail.   Note NIS/YP kept working.
I am not the author and am not that familiar with the protocols (they are not NFS),
but my understanding is that rpc.statd's job is to determine which other systems
are up and running and does IP broadcast etc to do so.

>Several questions:
>
>1. How do I make it so I can completely disconnect my LAN from the rest of
>the Internet and not have NFS fail like this?
Well, unless you run applications that concurrently share files across multiple clients
doing locking on them to co-ordinate their activities..
I recommend not using rpc.lockd/rpc.statd. If you do your mounts with the
option "nolockd" (called "nolock" on Linux, I think?), the locking is done locally
within the client and the daemons are not needed.
If you really need locking to work across multiple clients (as described above), I'd
recommend switching to NFSv4 mounts. (options "nfsv4,minorversion=1").

>2. Why does NFS require a live internet connection?
Sorry, don't know the answer to this, unless the loss of the cable modem somehow
affected IP broadcast.

rick, who refused to implement lockd/statd long ago, due to limitations (and lack of
         published specifications) of the protocols.