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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
