On 2004-03-31, Jeremy K <jkusnetz@yahoo.com> wrote:
> Without rpc.statd running on a client you have NFS locking problems.

I have not had any issues with locking when making extensive use of NFS,
starting only portmap on the clients. Possibly your exports or mounts need
a bit of tuning.

Michael

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 01 Apr 2004 00:58:27 GMT, Michael Shuler <michael@foobarra.org> wrote:
> On 2004-03-31, Jeremy K <jkusnetz@yahoo.com> wrote:
>> Without rpc.statd running on a client you have NFS locking problems.
>
> I have not had any issues with locking when making extensive use of NFS,
> starting only portmap on the clients. Possibly your exports or mounts need
> a bit of tuning.
>

Then you're not using programs which show up the problems.

After extensive use of NFS, problems only became evident when we started using
evolution and vic (videoconference tool) with NFS mounted home directories. All
problems were solved after editing rc.nfsd to run /rpc.lockd & rpc.statd even
when there were no /etc/exports entries.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAa62tEi1IpCjOY3ERAqIJAKDMic+W6L3b0T4+sNO/X8wfDZeq+gCgqpt9
p3popYlgRtSJUi9Ni+JDFMs=
=w+Cg
-----END PGP SIGNATURE-----

Chris Willing <chris@bogus.addr.invalid> wrote:
> After extensive use of NFS, problems only became evident when we started using
> evolution and vic (videoconference tool) with NFS mounted home directories.
> All problems were solved after editing rc.nfsd to run /rpc.lockd & rpc.statd
> even when there were no /etc/exports entries.

Hmm, my experience was the opposite, I recently DISabled running of rcp.statd
and (especially) rpc.lockd on pure NFS clients, as we had too many errors of
files locked when they shouldn't have been locked, so that for instance
cron jobs started generating errors on NFS mounted files.

Or even bad mounts after a server reboot, without the clients rebooting too.

PS: the way to easily enable rcp.statd/lockd is to add the simple line
#/
to the /etc/exports file (we used to have some commented-out entries like that
everywhere and I had to restore the original exports to disable rc.nfsd again).
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

> Then you're not using programs which show up the problems.
>
> After extensive use of NFS, problems only became evident when we started using
> evolution and vic (videoconference tool) with NFS mounted home directories. All
> problems were solved after editing rc.nfsd to run /rpc.lockd & rpc.statd even
> when there were no /etc/exports entries.

I agree these clients were up for a long time, but took a long time to
figure out why Frontpage Extentions weren't working on these boxes.
Started rpc.statd and boom it worked.

Anyone knows if this is fixed in the currents? How do we get the fix
put in?

On a Slackware 10.0 system, rpc.statd is not started if /etc/exports is
empty. If I run an application that does fcntl(...,F_SETLKW,...), then
it fails with ENLOCK if the file being locked is on an NFS mounted file
system. Once rpc.statd is started on the Slackware 10 client, the
fcntl no longer fails. I modified rc.nfsd to start statd and lockd
before checking /etc/exports so that applications doing F_SETLKW will
work properly. I sent a test program and my rc.nfsd modifications to
support@slackware.com so hopefully this will get fixed in the next
release.

My 2 cents
Ric
FWIW. I checked Fedore Core 3 and Solaris 8, and they start rpc.statd
and lockd even if the system is not an NFS server, and I haven't had
any of the F_SETLKW problems with Fedora or Solaris clients.