[OpenAFS-devel] Discarding tokens -- is this good?

[Robert Banz]

On Nov 11, 2006, at 12:15, Jeffrey Altman wrote:

> Robert:
>
> A "Tokens for AFS id ... have expired" means that the tokens are
> still being held by the cache manager and their expiration date has
> passed.   If the file server reported an RXKAD error indicating that
> the tokens were expired or bad, then the tokens would have been
> discarded.

> Hence, you are looking in the wrong place.  I would verify that your
> clocks are synchronized appropriately.

I don't know about that.  Clocks are A-OK.

However, from afs/afs_analyze.c:

...since

             if ((acode == VICETOKENDEAD) || (acode == RXKADEXPIRED))

Leads to the same message, I've added an extra bit to the  
"...expired" error message to tell me *which* of these is the case --  
but I'm pretty sure that from the client's perspective it's tokens  
shouldn't be expiring for quite awhile.

If it's the RXKADEXPIRED "reason", then it still leaves two problems:

1) why would you want to mark your tokens as "bad" just on the good  
word of someone you're communicating with.  (e.g., a fileserver)

2) why would a fileserver, assuming that all clocks are a-ok, return  
RXKADEXPIRED?  And, if we do get this error back (and our tokens  
don't look expired), shouldn't we just force a new RX connection and  
give it another shot, assuming it's just some sort of odd transient  
thing?

---

And, ...  great googly moogly -- after checking all of my log files,  
ONE of the servers that had the problem yesterday actually tossed a  
different reason:

19270410 = sealed data inconsistent

Something seems broken in wacky town -- and the fileservers seem to  
be keeping mum about it in their logs...  Anyhow, in case you're  
wondering: Client versions are 1.4.1 & 1.4.2; Server versions are  
1.4.2.  Both Solaris 10x86.

I have a cunning plan; focusing around #2 above...

-rob