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

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

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