Hello, Sam Hartman wrote: > > So, in particular, it looks like kdb5_util is acquiring a lock from 0 to > bignum that fails, acquiring a lock from 0 to 0 that succeeds, releasing > the lock from 0 to bignum (which succeeds?), and then while still > holding the lock from 0 to 0 tries to get another lock from 0 to bignum. > At least that's what it looks like if I'm reading that correctly. yes, that is how I interpret the trace. When the process waits for the lock, fuser shows that principal.ok is opened by the kdb5_util process.
> I don't know what the significance of 6950411022381350912 > I wonder if that's uninitialized memory of some kind. Hmm, I think len is allowed to be greater than the file's size. The above number is between 2^62 and 2^63. BTW, the test machines are 32 bit systems. Regards hmw
