[OpenAFS] Strange token issues
Shane Warner
shane.warner@gmail.com
Mon, 29 Apr 2013 13:36:04 -0700
--089e013d14ca726e3904db85d504
Content-Type: text/plain; charset=ISO-8859-1
Hi Russ,
Yes we are running on CentOS 6.4 linux.
No we have not increased both values, they are currently set to 200 by
default. We will definitely try increasing these values and see if the
problems are resolved. Is there a risk this will keep filling up even with
a substantial increase, assuming this is the issue?
Thanks,
Shane
On Mon, Apr 29, 2013 at 1:22 PM, Russ Allbery <rra@stanford.edu> wrote:
> Shane Warner <shane.warner@gmail.com> writes:
>
> > We are having some strange issues with tokens on our openafs 1.6.2
> > environment.
>
> > There are 3 scenarios that randomly appear on our clients running apache
> > with mod_waklog:
> > 1) Tokens become invalid and an rxkad error=19270408 appears in dmesg.
> This
> > is the least prevalent issue, and has only happened a couple of times.
> > 2) Permission denied errors are seen intermittently while accessing
> files.
> > Some file accesses are successful, some fail. No errors in logs on this
> one.
> > 3) There is no intermittent behavior, just a solid permission denied even
> > though it would appear that a token has been obtained. Restarting the
> > openafs-client/httpd resolves it for about a minute before the permission
> > denied brick wall comes back. No errors in logs on this one.
>
> > Only rebooting the entire system resolves the issues for all of the above
> > situations. Situations 2 and 3 are by far the most common and occur every
> > 3-7 days on clients.
>
> I assume this is Linux. Have you increased:
>
> /proc/sys/kernel/keys/maxkeys
> /proc/sys/kernel/keys/root_maxkeys
>
> on your systems? mod_waklog can generate a lot of PAGs, which means that
> you can run out of kernel keyrings, and that will prevent credentials from
> being stored.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--089e013d14ca726e3904db85d504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Russ,<div><br></div><div>Yes we are running on CentOS 6=
.4 linux.</div><div><br></div><div>No we have not increased both values, th=
ey are currently set to 200 by default. We will definitely try increasing t=
hese values and see if the problems are resolved. Is there a risk this will=
keep filling up even with a substantial increase, assuming this is the iss=
ue?</div>
<div><br></div><div>Thanks,</div><div>Shane<br><div class=3D"gmail_extra"><=
br><br><div class=3D"gmail_quote">On Mon, Apr 29, 2013 at 1:22 PM, Russ All=
bery <span dir=3D"ltr"><<a href=3D"mailto:rra@stanford.edu" target=3D"_b=
lank">rra@stanford.edu</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Shane Warner <<a href=
=3D"mailto:shane.warner@gmail.com">shane.warner@gmail.com</a>> writes:<b=
r>
<br>
> We are having some strange issues with tokens on our openafs 1.6.2<br>
> environment.<br>
<br>
> There are 3 scenarios that randomly appear on our clients running apac=
he<br>
> with mod_waklog:<br>
> 1) Tokens become invalid and an rxkad error=3D19270408 appears in dmes=
g. This<br>
> is the least prevalent issue, and has only happened a couple of times.=
<br>
> 2) Permission denied errors are seen intermittently while accessing fi=
les.<br>
> Some file accesses are successful, some fail. No errors in logs on thi=
s one.<br>
> 3) There is no intermittent behavior, just a solid permission denied e=
ven<br>
> though it would appear that a token has been obtained. Restarting the<=
br>
> openafs-client/httpd resolves it for about a minute before the permiss=
ion<br>
> denied brick wall comes back. No errors in logs on this one.<br>
<br>
> Only rebooting the entire system resolves the issues for all of the ab=
ove<br>
> situations. Situations 2 and 3 are by far the most common and occur ev=
ery<br>
> 3-7 days on clients.<br>
<br>
</div>I assume this is Linux. =A0Have you increased:<br>
<br>
=A0 =A0 /proc/sys/kernel/keys/maxkeys<br>
=A0 =A0 /proc/sys/kernel/keys/root_maxkeys<br>
<br>
on your systems? =A0mod_waklog can generate a lot of PAGs, which means that=
<br>
you can run out of kernel keyrings, and that will prevent credentials from<=
br>
being stored.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Russ Allbery (<a href=3D"mailto:rra@stanford.edu">rra@stanford.edu</a>) =A0=
=A0 =A0 =A0 =A0 =A0 <<a href=3D"http://www.eyrie.org/~eagle/" target=3D=
"_blank">http://www.eyrie.org/~eagle/</a>><br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
</font></span></blockquote></div><br></div></div></div>
--089e013d14ca726e3904db85d504--