Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jun 2006 19:46:53 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Andrew Reilly <andrew-freebsd@areilly.bpc-users.org>
Cc:        Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-arch@FreeBSD.org
Subject:   Re: What's up with our stdout?
Message-ID:  <20060626194341.I67977@delplex.bde.org>
In-Reply-To: <20060626181131.G67741@delplex.bde.org>
References:  <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> <20060625020154.GA89358@gurney.reilly.home> <20060626002658.A65226@delplex.bde.org> <20060625213605.GA93766@duncan.reilly.home> <20060626181131.G67741@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jun 2006, I wrote:

> Configuring of locking for nfs is confusing and poorly documented.
> Neither rpc.lockd nor rpc.statd gets started automatically when a file
> system is nfs-mounted without nolockd.  This wouldn't be easy to
> automate, since the daemons must be started on both the clients and
> servers.  mount_nfs(8) doesn't say clearly which daemons must be started
> where.  rc.conf(5) says wrongly that rpc_lock_lockd and rpc_statd_enable
> only apply to servers.  Starting them both on clients and servers seems
> to be needed.  With a filesystem nfs-remounted without nolockd: there
> seem to be ordering or timing requirements for starting them -- starting
> them manually sometimes gave a useful error message for flock() attempts
> when not all were started, but sometimes starting them all didn't stop
> flock() from failing and other times gave a hung flock().  Killing and
> restarting rpc.lockd on the client (while leaving the other daemons
> running) usually worked to unhang flock() and make it work on the next
> try.

I didn't actually find a usable configuration of nfs locking, since the
above left rpc.lockd taking 100% CPU on both the client and server.
This was with FreeBSD-~5.2.  Some of the many bugs in rpc.lockd have been
fixed since 5.2.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626194341.I67977>