On Fri, Apr 18, 2008 at 02:11:55PM -0400, Janne Karhunen wrote:
> On Fri, Apr 18, 2008 at 1:36 PM, J. Bruce Fields <[email protected]> wrote:
> > > Apparently lockd does not expect statd to be used with -n
> > > switch: statd is expected to bind loopback, always. Attached
> > > patches show one (IPv4 specific) way of fixing it. Comments?
> > Maybe statd really should always bind to the loopback interface? Is
> > there any reason not to?
> In my case I used -n to push NSM/NLM comms to
> clusters specific NFS service address (that just
> happens to migrate all around). -n is the only way
> to do this: otherwise it will bind to INADDR_ANY
> on node that has gazillion interfaces/addresses..
> That, and the original reasoning for the option is
> said in statd code:
> * If a local hostname is given (-n option to statd), bind to
> the address
> * specified. This is required to support clients that ignore
> the mon_name in
> * the statd protocol but use the source address from the
> request packet.
Weird--I dont' see that comment.
> > From a quick look at the current nfs-utils code: it looks like the -n
> > option only affects the operation of the sm-notify program that's called
> > on boot to notify peer statd's? I'm a little confused. (What version
> > of nfs-utils are you working from?)
> Right. 1.0.8 -> 1.0.12, it's valid for all.
Oh, OK. Looks like the change was made for 1.1.0; do nfs-utils more
recent than that work for you?
On Fri, Apr 18, 2008 at 2:25 PM, J. Bruce Fields <[email protected]> wrote:
> > /*
> > * If a local hostname is given (-n option to statd), bind to
> > the address
> > * specified. This is required to support clients that ignore
> > the mon_name in
> > * the statd protocol but use the source address from the
> > request packet.
> > */
> Weird--I dont' see that comment.
All original nfs-utils-1.0.12 tarball; indeed strange.
But to be honest, I don't instantly understand how
this would work without -n at all (apart blind luck).
INADDR_ANY has no guarantees..