Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown

[quanah@stanford.edu]

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