Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Length: 1907
I have yet to find the kdb5_util bug too... it happens semi-regularly except when I try to reproduce it. And it turns out there is a third problem... I will send another patch shortly which should be safer and which supersedes both patches though the original can stay...

Richard Basch

(Sent via my Samsung GALAXY S™4)

-------- Original message --------
From: Greg Hudson via RT <>
Date: 08/21/2013 16:12 (GMT-05:00)
Subject: [ #7695] krb5-1.11.3/1.10.6 - full resync may fail and still result in ulog being updated

Sending to krb5-bugs is sufficient; you do not need to forward to krb5-
bugs and krbdev.

I do not really understand how kdb5_util could exit with status 2
(implying that it got all the way through load_db(), since nothing in
the code calls exit(2)) but not reset the ulog header with the code in
your earlier patch from issue #7588.  Also, I would really love to know
in what way kdb5_util load is sometimes failing, since that should be
rare.  Unfortunately, kdb5_util was written as a command-line tool and
not a component of a server, so when it fails, it just writes to stderr
instead of logging.

Rather than add a redundant second piece of code to reinitialize the
ulog header on failure, I wonder if we should make load_db() leave the
ulog header alone until after it has called krb5_db_promote().  I don't
see any point in having a window where the ulog header doesn't reflect
the status of the live database.