From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: "Server not responding" after periods of client
	inactivity
Date: Tue, 09 Aug 2005 16:59:20 -0400
Message-ID: <1123621160.8245.200.camel@lade.trondhjem.org>
References: <20050714212514.GA23867@fox> <20050730131031.GA1668@fox>
	 <1122732943.8248.13.camel@lade.trondhjem.org> <20050730143216.GA2339@fox>
	 <1122735345.8248.28.camel@lade.trondhjem.org>
	 <20050809190634.GA5779@fox.upc.no>
	 <1123614892.8245.166.camel@lade.trondhjem.org>
	 <20050809203219.GA6740@fox.upc.no>
Mime-Version: 1.0
Content-Type: text/plain
Cc: nfs@lists.sourceforge.net
To: Haakon Riiser <haakon.riiser@fys.uio.no>
In-Reply-To: <20050809203219.GA6740@fox.upc.no>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

ty den 09.08.2005 Klokka 22:32 (+0200) skreiv Haakon Riiser:
> Done.  Unfortunately, I couldn't find a call trace for mountd,
> I only got this:
> 
> rpc.mountd    R running  1880  2814      1               18906 (NOTLB)

Makes sense. That means that rpc.mountd is hanging in userland. That
would also explain why you can't immediately ptrace it.

It is worrying, though. rpc.mountd should almost always be in the
kernel, waiting in select().

Did you compile this version of rpc.mountd yourself? If not, is there
anything special/weird in your /etc/exports file that might cause the
rpc.mountd parser to be screwing up?

Cheers,
  Trond


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs