libkadm5 locks only the policy database when updates to the policy database. One possible trigger condition is: * create_principal gets write lock on policy db to update policy refcount * krb5kdc races against this, trying to read-lock both principal db and policy db (krb5_db2_get_principal gets locks on both) ** the principal db lock succeeds, but policy db lock fails ** error path in krb5_db2_lock calls krb5_db_unlock, which fails to unlock the non-locked policy db, and due to this bug, skips the code to unlock the principal db * krb5kdc ends up with a persistent read lock on the principal db Another possibility is lockout updates by the KDC racing against policy lookups (from password changes) by kadmind.