Content-Type: text/html; charset=utf-8
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...
(Sent via my Samsung GALAXY S™4)
-------- Original message --------
From: Greg Hudson via RT <firstname.lastname@example.org>
Date: 08/21/2013 16:12 (GMT-05:00)
Subject: [krbdev.mit.edu #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.