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