Subject: nfslocking problem persists?
To: None <current-users@NetBSD.org, port-sparc@NetBSD.org>
From: John D. Baker <email@example.com>
Date: 05/21/2006 15:11:52
I recently upgraded my file server from NetBSD/sparc-1.6 to v3.99.4
(and then to 3.99.17) and started having a lot of problems with NFS
locking, particularly with Mozilla Firefox on MacOS X client systems.
The MacOS X systems would claim that the NFS server (where user home
directories live) could not be contacted. I would choose the option
to keep trying (the other option was to disable locking). Firefox
would be basically frozen.
I would then ssh into the fileserver and restart nfslocking
When it would attempt to kill rpc.lockd and rpc.statd, it would print:
Waiting for PIDS: 586.
lockd not running?
So, at some point, rpc.lockd had quit. (If I restarted again right away,
it would wait for each PID and not complain about 'lockd not running?'.)
Once restarted, the clients would eventually start working again. The
server then records many, many instances of:
rpc.lockd: no matching entry for <clientname>
last message repeated 26 times
So far, the only reference to such messages has been:
Just in case my 3.99.4 and 3.99.17 builds might still be suffering
from the problem, I deleted the /var/db/statd.status file and restarted
all the NFS services. This has decreased the frequency of the problem,
but not eliminated it altogether.
I never had these problems when running NetBSD 1.6 on the file server.
I would have to occasionally restart nfslocking, but that was usually
due to a client machine failing to unmount its NFS filesystems (due
to crash or power failure), causing excessive load on the server from
multiple copies of statd with no matching client.
Any ideas of what may yet be happening? Thanks.
John D. Baker, KN5UKS NetBSD Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com OpenBSD FreeBSD
BSD -- It just sits there and _works_!
GPG fingerprint: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645