Date: Mon, 12 May 2003 17:01:39 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: rpc.lockd spinning; much breakage Message-ID: <Pine.NEB.3.96L.1030512165906.76804Q-100000@fledge.watson.org> In-Reply-To: <200305122039.h4CKdMM7048544@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 May 2003, Don Lewis wrote: > > The rpc.lockd process remains extremely busy even after crash2 is rebooted > > and the stream of packets is no longer present. > > > > I'm not sure how to go about debugging these problems, but the current > > scenario basically means I can't get both the crash boxes through their > > daily events if both the client and server are very busy (i.e., if they > > both run their daily events at the same time). I'm going to reboot cboss > > and the systems and see if that flushes whatever nasty state hangs around, > > but any advice on the debugging process would be helpful. Is there a way > > to get rpc.lockd on the server to dump it's state to a file? > > Why not attach the process in gdb and step through the code to find the > loop? Well, I guess the problem is I'm not familiar with the NFS lock manager protocol, and what I'm looking for more is debugging advice: is the best approach to attach to the client or server rpc.lockd? I had a lot of trouble getting ethereal to work well for debugging NLM stuff as it tended to crash. :-) Things are somewhat complicated by the fact that once you lose the rpc.lockd on a client, lots of programs begin to hang and stack up... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030512165906.76804Q-100000>