[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