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_at_fledge.watson.org Network Associates LaboratoriesReceived on Mon May 12 2003 - 12:01:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC