Strange full resync on a quiet day
John Devitofranceschi
jdvf at optonline.net
Sun Jul 19 08:01:15 EDT 2015
We just finished updating our KDC infra to 1.13.2 and I noticed this today.
It was a very quiet day and, after a test "kproplog -R" on the master to make sure iprop_resync_timeout was sufficient (it was) all the slaves did two FULL_RESYNCs (I know why; I'm looking forward to 1.14) and then a couple of incremental updates came though.
For the next 8 hours and a bit, "kpropog -h’ on the master reported this:
Kerberos update log (/var/krb5/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 2048
Number of entries : 2
First serial # : 1
Last serial # : 2
First time stamp : Sat Jul 18 13:05:57 2015
Last time stamp : Sat Jul 18 13:12:14 2015
A change came in at 21:30 and this seems to have reset the ulog in some way:
Kerberos update log (/var/krb5/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 4096
Number of entries : 2
First serial # : 3
Last serial # : 4
First time stamp : Sat Jul 18 21:30:17 2015
Last time stamp : Sat Jul 18 21:30:17 2015
(these updates were a kadm5_chpass_principal and a kadm5_modify_principal, if that matters)
The iprop requests that came in immediately after this were FULL_RESYNCs (only one for each slave this time). A subsequent update made it to the slaves in the usual, incremental, way.
Any idea what caused the full resyncs on such a quiet day? Nothing in the logs sheds any light on this for me and a glance over lib/kdb/kdb_log.c left me none the wiser.
jd
More information about the Kerberos
mailing list