Re: /var/lib/nfs/sm/ files

[Christian Reis <kiko@async.com.br>]

On Wed, Jan 08, 2003 at 01:46:10PM +0100, Trond Myklebust wrote:
> >     - Why do most entries' mtime get updated periodically, but a few of
> >       the entries go stale with time?
> 
> The file should get deleted every time the client releases all locks and 
> successfully manages to notify the server that it is stopping monitoring.

Aha, this makes a lot of sense. Then the leftover files I am getting are
probably a product of:

syslog:Jan  7 08:35:47 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4
syslog:Jan  7 09:09:37 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4
syslog:Jan  7 18:23:15 canario rpc.statd[101]: Received erroneous SM_UNMON request from canario for 192.168.99.4

It seems that rpc.statd itself isn't liking the request it's getting and
never forwards it to the server. I used to think these were harmless,
but now I wonder why would this be happening?

> >     - Why do some of the stale entries get left over even after the
> >       workstations have halted (these ones present the nfs hang issue)?
> 
> 
> As I've told you before: 'stale' entries, as you call them, indicate that the 

(Sorry, I am apparently clueless when it gets to these details.)

> rpc.statd never managed to notify the server that it should stop monitoring. 
> It indicates either the server or the client crashed before the POSIX locks 
> held by the client got released, or possibly that the rpc.statd processes 
> crashed (or got 'kill -9' ed).

But at least it seems that nobody has crashed - statd is running along
fine. Both server and clients run the same versions of the daemon, and
the fact that we get repeated messages (without restarting anybody)
should indicate that it is in fact running. 

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL