[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
I've finally figured out how to reproduce this -- The problem is related to
the log purging done by access log. Here is what I did:
Make changes to the database, that were replicated. Everything is happy.
Shut down slapd, modify the logpurge parameter so that log purging is done.
Restart slapd
Verified that log purging was done, and that everything was still happily
in sync.
Stop slapd, restart slapd
Now the access log DB has generated a new CSN that is in the future of the
suffix stored CSN.
So it appears that somehow the logpurge operation either causes a new
contextCSN to be written at the time the server is shut down, or it erases
the contextCSN held by the accesslog db.
Now, this is when I restarted slapd:
Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct
26 2006 13:41:27) $
^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd
However, the contextCSN that was generated is:
contextCSN: 20061107002625Z#000000#00#000000
This matches the time at which I started slapd when log purging was run:
Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct
26 2006 13:41:27) $
^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd
so I'd say that when log purge is run, it resets the contextCSN in the
accesslog DB to the time at which slapd last started...
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html