Date: Wed, 28 May 2008 21:14:35 +0100 From: Doug Rabson <dfr@rabson.org> To: Arno J. Klaassen <arno@heho.snv.jussieu.fr> Cc: stable@freebsd.org, net@freebsd.org Subject: Re: nfs buildworld blocked by rpc.lockd ? Message-ID: <5E032C03-6857-4E7F-9C3D-B5C06A79934C@rabson.org> In-Reply-To: <wpk5hew6aw.fsf@heho.snv.jussieu.fr> References: <wpk5hew6aw.fsf@heho.snv.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 May 2008, at 20:57, Arno J. Klaassen wrote: > > Hello, > > my buildworld on a 7-stable-amd64 blocks on the following line : > > TERM=dumb TERMCAP=dumb: ex - /files/bsd/src7/share/termcap/ > termcap.src < /files/bsd/src7/share/termcap/reorder > > ex(1) stays in lockd state, and is unkillable, either by Ctl-C or > kill -9 > > /files/bsd is nfs-mounted as follows : > > push:/raid1/bsd /files/bsd nfs > rw,bg,soft,nfsv3,intr,noconn,noauto,-r=32768,-w=32768 0 0 > > I can provide tcpdumps on server and client if helpful. I would very much like to see tcpdumps (from either client or server). This problem is often caused by the fact that unless you use the '-p' flag, rpc.lockd isn't wired down to any particular port number. Since it is started at boot time, it will usually end up with the same one each time but the new kernel implementation in 7-stable typically ends up with a different port number to the old userland implementation. Quirks of the locking protocol make it difficult for the server to notice this without a lengthy timeout. Workarounds include using '-p' to wire it down to a consistent port (port 4045 is reserved for this) or restarting rpc.lockd on the server.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5E032C03-6857-4E7F-9C3D-B5C06A79934C>