On a master KDC with iprop enabled, krb5_db_put_principal and krb5_db_delete_principal behave as follows: * Lock the ulog * Add an uncommitted update record to the ulog * Perform the DB operation * Finalize the update record * Unlock the ulog The DB2 back end implicitly locks the database during the database operation, so the total effect is lock the ulog, lock the DB, unlock the DB, unlock the ulog. However, if a program obtains an explicit lock with krb5_db_lock and then changes a principal, the order of lock acquisition is reversed (DB before ulog). Depending on the kernel, this will result in either actual deadlock, or an EDEADLK error and a failed operation. This reversed acquisition order happens in two cases: kdb5_util update_princ_encryption and kdb5_util load -update.