--On Monday, October 09, 2006 6:42 PM +0000 quanah@stanford.edu wrote:

Then, I did the following:

(a) stop slapd (b) remove the current accesslog db (since all slaves are in sync) (c) get the contextCSN:

dn: cn=accesslog contextCSN: 20061009183830Z#000000#00#000000

(d) stopped slapd

(e) started slapd

(f) queried, the contextCSN is the same(?!!)

ldap-test0:~> ldapsearch -LLL -Q -h localhost -b cn=accesslog -s base contextCSN dn: cn=accesslog contextCSN: 20061009183830Z#000000#00#000000

(g) Made a modification

(h) got the current contectCSN:

dn: cn=accesslog contextCSN: 20061009184042Z#000000#00#000000

(i) Stopped slapd

(j) restarted slapd

(k) got the contectCSN:

dn: cn=accesslog contextCSN: 20061009184042Z#000000#00#000000

It is the same again. So at best guess, something "corrupted" the accesslog DB somehow? I'm not really sure. I will monitor to see if I get back into the same situation again.

I've recreated the accesslog DB in all my environments, and now this problem is gone. Either some earlier release of OpenLDAP 2.3 created a funky accesslog DB that it wasn't happy with, or there's a state that can get triggered that causes it to always recreate the contextCSN, I'm not sure what that would be. In any case, I think this ITS can be closed for now. If my servers get back into this state, then we'll know there's some underlying bug that causes it that needs to be found.

--Quanah

-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html