--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