On Wed, 2008-02-13 at 08:58 +0000, Nix wrote: > I upgraded from 2.6.23.10 to 2.6.24.2 yesterday, and found NFS service > failing. > > To be specific, all locks were blocking forever, with an endless flood > of > > Feb 12 22:53:10 loki notice: kernel: statd: server localhost not responding, > timed out > Feb 12 22:53:10 loki notice: kernel: lockd: cannot monitor esperi > Feb 12 22:53:45 loki notice: kernel: statd: server localhost not responding, > timed out > Feb 12 22:53:45 loki notice: kernel: lockd: cannot monitor esperi > Feb 12 22:54:20 loki notice: kernel: statd: server localhost not responding, > timed out > Feb 12 22:54:20 loki notice: kernel: lockd: cannot monitor esperi > Feb 12 22:54:55 loki notice: kernel: statd: server localhost not responding, > timed out > Feb 12 22:54:55 loki notice: kernel: lockd: cannot monitor esperi > Feb 12 22:55:20 esperi notice: kernel: lockd: server loki.wkstn.nix not > responding, still trying > > (esperi is a UML instance on the same machine, connected via a bridged > TUN/TAP interface: the bridge, and network service to esperi and to the > rest of the local net across that bridge, was fine.) > > I'm currently using NFSv3 atop nfs-utils 1.1.0.33-gdd08789, with daemons > being started in the suggested order (portmap, mountd, statd > --no-notify, nfsd). This evening I'm going to try to upgrade to > nfs-utils HEAD and see if this continues.
Nothing has changed w.r.t. the statd interface. My 2.6.24 nfsv3 machines are working without a hitch. Do 'rpcinfo' and 'netstat -p' show that rpc.statd is listening on a privileged port? Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
