Re: `rpc.nfsd #` gets hung up when loopback iface is down

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 1491 bytes --]

On Monday, August 30, 2010 13:03:16 Chuck Lever wrote:
> On Aug 28, 2010, at 4:46 PM, Mike Frysinger wrote:
> > is it expected behavior that `rpc.nfsd #` gets hung up whenever the
> > loopback interface hasnt been configured ?  even `rpc.nfsd 0` which
> > seems a bit odd. 
> 
> NFS doesn't work without lo being configured.  We don't test that scenario,
> normally, so I wouldn't say specifically that we expect this particular
> behavior.  However, since rpc.nfsd might require the kernel to use the
> local portmapper, yes, it probably will hang without "lo".
> 
> We had a similar report earlier this year on client side misbehavior when
> lo was not configured.  It was a root-on-NFS situation where an NFS mount
> was done before networking was fully configured.
> 
> The kernel's portmapper client now uses TCP to contact the local portmapper
> so that it can detect immediately when there is no local portmapper
> running.  Normally, if a physical interface is down, operations on a TCP
> socket will fail.  Apparently this has never been the case for "lo".
> 
> Usually our solution to this problem is "Don't try to use NFS without lo". 
> But please let us know what your use case is.

i had a user who attempted to start nfs services but had removed the net.lo 
service (presumably by accident).  i just told them "dont do that".  so i dont 
have a real use case that demands no loopback interface.  just making upstream 
aware of possible bugs.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]