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