On Wed, Feb 22, 2006 at 01:05:23AM -0600, Ryan Underwood wrote: > > > > Tokens can be lost because of either local issues such as the pag being > > cleared via an 'unlog' or a new pag being allocated. The tokens could > > be lost due to a bug in the client. Or the tokens could be lost because > > the server has reported to the client that the tokens cannot be used > > due to RXKADUNKNOWNKEY, RXKADBADTICKET, RXKADEXPIRED, etc. The first > > thing you need to determine is which it is. > > > > If the server is the trigger of the token loss, an event will be written > > to the cache manager trace log within the kernel (if the log is active.) > > You can control the use of the cm event logging with the 'fstrace' > > options 'lsset', 'setset' and 'dump'. > > > > Activate the event logging and when the problem occurs, dump the output > > to a file and search it for a tokens discarded message. If found, the > > message will indicate the error value that caused the tokens to be > > cleared. Depending on why the tokens are being cleared there are > > different next steps. > > OK, I issused fstrace setset, then fstrace lsset: > Available sets: > cmlongterm active > cm active > > Then I waited for the token to be lost, then I fstrace dump. But the > word 'token' does not appear in the output. I tried fstrace dump, > fstrace dump cm, and fstrace dump cmlongterm. Did I do this correctly?
So, assuming I did this correctly, there must be a client bug, since nothing in this pag is issuing unlog and the server is not invalidating the token? -- Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
