I've installed 1.4.10 on a linux afs server geronimo and linux client ookpik

the client works on geronimo but uses 96% of 8 cpu's on ookpik which also
has a kernel message rxaderrror

An untouched previously working XP client also hangs at 100% CPU but
eventially carps "attempt to compromise security" when the afs shares are
selected.

Some key ot cc file may have been munged on geronimo but /tmp/krb5_cc0
/etc/krb5.keytab appear to be consistent now - checked with
asetkey
klist
kvno

They wern't consistent previously..

Any testing I can do I will..

On Tue, Apr 21, 2009 at 8:32 AM, Jeffrey Altman <
[email protected]> wrote:

> Mircea Ciocan wrote:
>
> > IMHO, no matter what kerberos key  b..s is happening this should not
> > produce this miserable kernel loop that kills the most powerful machines
> > available today, it either should have some slower cadence so that
> > eventually some could stop the AFS processes or it should give up after
> > some time, I this regard I consider this behavior a bug.
> >
> > Cheers,
> > Mircea
>
> In the good old days when server-A reported "bad kvno" the cache manager
> would discard the token even though it was possible that the token was
> in fact valid and would work on every other server in the cell.  This
> is frequently a problem when a cell contains a mixture of pre-OpenAFS
> 1.2.8 or Transarc/IBM servers and post-OpenAFS 1.2.8 servers.
>
> A few releases ago a modification was made to prevent the token from
> being discarded and in the case of a replicated volume, to permit fail
> over to an alternate copy.
>
> I suspect the issue is somehow related to this because now the afs
> client will return a bad kvno error to the application instead of
> access denied.  If the application repeatedly retries the request
> the kernel module will just ask the file servers again and produce the
> same result.  If the application asks again, ....
>
> It would be helpful to know if the infinite loop is being driven by
> the application or is strictly within the kernel module.
>
> Jeffrey Altman
>

Reply via email to