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

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

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.
-mike

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

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

[Chuck Lever]

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.
> -mike

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.

-- 
chuck[dot]lever[at]oracle[dot]com

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

[Mike Frysinger]

[-- 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 --]