--On Sunday, October 08, 2006 11:36 AM +0000 openldap-its@OpenLDAP.org wrote:

I did some testing, and found that the problem is that accesslog is creating a new contextCSN every time slapd is started. Here's my testing:

(a) Search accesslog for its contextCSN:

ldap-test0:/tmp# cat contextCSN.before dn: cn=accesslog contextCSN: 20061009111121Z#000000#00#000000

(b) Stop slapd, dump the accesslog DB to LDIF, look at the entry values:

ldap-test0:/tmp# cat contextCSN.LDIF dn: cn=accesslog objectClass: auditContainer cn: accesslog entryCSN: 20060829205636Z#000000#00#000000 structuralObjectClass: auditContainer contextCSN: 20061009111121Z#000000#00#000000

(c) Start slapd, query accesslog for its contextCSN:

ldap-test0:/tmp# cat contextCSN.startup dn: cn=accesslog contextCSN: 20061009183449Z#000000#00#000000

As you can see, a new version was generated at startup, rather than it keeping the one it had at shutdown. Why, I don't know.

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.

--Quanah

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