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:
signature.asc
Description: This is a digitally signed message part.
