Re: "Server not responding" after periods of client inactivity

[Haakon Riiser <haakon.riiser@fys.uio.no>]

Trond,

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

But shouldn't strace immediately attach, even if mountd is
busy-waiting in userspace?  E.g., if I create a program that loops
forever, such as

  for (;;) { }

I can still attach immediately, although nothing is printed since
there are no system calls (I've verified this).  How can a program
running in userspace delay strace's initial attachment?

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

No and no.  I'm using Fedora Core 3's rpc.mountd (nfs-utils-1.0.6-52),
and this is my /etc/exports:

/pub    10.0.0.4(rw,async,no_root_squash,no_subtree_check)
/raid   10.0.0.4(rw,async,no_subtree_check)
/pub    10.0.0.21(rw,async,no_root_squash,no_subtree_check)
/raid   10.0.0.21(rw,async,no_subtree_check)

Shouldn't have any problems with this, right?

-- 
 Haakon


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