Debugging a hung connection

[J. Bruce Fields]

On Wed, May 21, 2008 at 11:55:08AM -0400, Norman Elton wrote:
> Dave / Bruce,
> 
> >
> > Well, the simplest thing to look for would just be any rpc calls that
> > don't get replies.  What exactly are the client and server?
> >
> 
> Thanks for the leads. I've enabled rpcdebug (very handy, hadn't seen
> it before!) on the server and both a working and non-working client to
> compare results.
> 
> The dead client stops at:
> 
> May 21 11:42:09 auth3 kernel: NFS: atomic_lookup(0:15/1769473), test
> May 21 11:42:09 auth3 kernel: RPC:     looking up RPCSEC_GSS cred
> 
> In this case, I'm trying to touch a file called "test". Interestingly,
> in the working client, I never see a call to atomic_lookup.
> 
> What would cause one client to call this function, but another not to?

I don't know, but that may be a red herring--the RPCSEC_GSS lookup seems
a more likely cause for delay.  I gssd running on that client?  Have you
tried turning on its debugging?  Could it be having trouble reaching the
kerberos server?

--b.

> 
> My PCAPs indicate that every RPC request packet is answered with a
> reply. Not sure how to dig deeper into the wireshark output.
> 
> Hmm...
> 
> Thanks again for your help!
> 
> Norman Elton
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4