From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:38:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DAC1065674 for ; Tue, 30 Mar 2010 15:38:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7130E8FC1A for ; Tue, 30 Mar 2010 15:38:42 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id zNnY1d0031swQuc55Teils; Tue, 30 Mar 2010 15:38:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.westchester.pa.mail.comcast.net with comcast id zTiv1d00L3S48mS3bTiwrr; Tue, 30 Mar 2010 15:42:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F2E089B419; Tue, 30 Mar 2010 08:38:39 -0700 (PDT) Date: Tue, 30 Mar 2010 08:38:39 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20100330153839.GA32700@icarus.home.lan> References: <20100329165647.GA3796@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Strange NFS-related messages (related to lockd/statd) 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: Tue, 30 Mar 2010 15:38:42 -0000 On Tue, Mar 30, 2010 at 10:45:09AM -0400, Rick Macklem wrote: > > > On Mon, 29 Mar 2010, Jeremy Chadwick wrote: > > >I recently brought up rpc.lockd and rpc.statd on all of our NFS clients > >(mixed RELENG_6, RELENG_7, and RELENG_8), and our NFS server (RELENG_8). > > > >All clients had nfs_client_enable="yes" in rc.conf prior to their last > >reboot, but lacked rpcbind_enable="yes", rpc_lockd_enable="yes", and > >rpc_statd_enable="yes" prior to the below. > > > >The 8.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > > >NLM: failed to contact remote rpcbind, stat = 0, port = 0 > >Can't start NLM - unable to contact NSM > > > >The 7.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > > >Can't start NLM - unable to contact NSM > > > Oh, I forgot to mention..I can't help much, but these protocols/daemons > are SunRPC, so they will be using portmapper (now called rpcbind) to get > port #s assigned dynamically. I also believe (not sure, don't know much > about it) that the NSM will poll for other machines, so it needs to be > able to talk to all clients and server(s), including doing IP broadcast > that gets to them all. (These were designed in the 1980s for a LAN, which > was just a chunk of coax in those days:-) > > Hope this helps, rick In fact it did! Your hint lead me to try my earlier idea: using the -h flag to rpcbind. Turns out lockd wasn't running on any of the systems (rpcinfo didn't show it, and ps didn't show it). I ended up modifying all of the boxes to use: rpcbind_flags="-h " (Where em1=LAN, em0=WAN. em0 contains the default route as well) Restarted rpcbind + statd + lockd (in that order). Voila, everything started up, and no messages. rpcinfo shows all correct services. So my guess is that by binding to INADDR_ANY by default, packets were going out the primary interface (em0) or going to broadcast on em0 -- which would return nothing, since pf blocked such packets. Makes sense to me anyway. Thanks! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |