On 12 May, Robert Watson wrote: > On the server side, rpc.lockd is unusually busy as a result: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 47547 root 121 0 1592K 1224K RUN 448:30 98.68% 98.68% rpc.lockd > > Usually the behavior that upsets the client is to run: > > while (1) > periodic daily > periodic weekly > periodic monthly > end > > 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?Received on Mon May 12 2003 - 11:39:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC