What's up with our stdout?
Bruce Evans
bde at zeta.org.au
Mon Jun 26 09:47:06 UTC 2006
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
More information about the freebsd-arch
mailing list