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