Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Length: 1525

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 <rt-comment@krbdev.mit.edu> 
Date: 08/21/2013  16:12  (GMT-05:00) 
To: basch@alum.mit.edu 
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.