On Thu, 2 May 2013, Troy Telford wrote:
Package: krb5-kdc
Version: 1.10.1+dfsg-5
Severity: normal
Dear Kerberos Maintainer,
I now have two entirely unrelated systems with this behavior. It cropped up
about 3-4 weeks ago.
I doubt it's the KDC; I only know it's kerberos related. I honestly don't know
exactly what is the root cause, but it has something to do with apps that
authenticate using kerberos.
Both use Kerberos & LDAP, but are on entirely different networks (ie. home &
office), which are not connected.
When a user attempts to authenticate, the authenticating program then appears
to freeze, and consumes 100% CPU.
3-4 weeks ago would correlate with the 1.10.1+dfsg-5 upload, but the only
client change in that version is a workaround for a getaddrinfo bug,
changing the input flags from AI_CANONNAME | AI_ADDRCONFIG to just
AI_CANONNAME. Furthermore, this codepath is only reached when generating
a principal name for a host-based service principal, which is certainly
not the case when a normal user runs 'kinit'.
I fear we will need a stack trace for one of the spinning processes to
have a better idea of what it's doing. 'echo t > /proc/sysrq_trigger' may
catch this process' stack trace (but if it is spinning that may not be
considered "blocked"). gcore or gdb are more certain to be able to gather
information on the call stack.
-Ben Kaduk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
