From owner-freebsd-stable@FreeBSD.ORG Wed May 28 20:14:38 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1991065670; Wed, 28 May 2008 20:14:38 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 1936F8FC19; Wed, 28 May 2008 20:14:38 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 6A5F63F8F; Wed, 28 May 2008 21:14:36 +0100 (BST) Message-Id: <5E032C03-6857-4E7F-9C3D-B5C06A79934C@rabson.org> From: Doug Rabson To: Arno J. Klaassen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 21:14:35 +0100 References: X-Mailer: Apple Mail (2.919.2) Cc: stable@freebsd.org, net@freebsd.org Subject: Re: nfs buildworld blocked by rpc.lockd ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2008 20:14:38 -0000 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.