[Date Prev][Date Next]
Re: (ITS#5065) out of order ctxcsn from old entryCSN
> Full_Name: Donn Cave
> Version: 2.4.4
> OS: RH Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (18.104.22.168)
> Old entryCSN values imported into the data from another server, can crash
> In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose
> value is less than its matching si_cookieState->cs_val. This breaks out of the
> inner loop, and the outer loop, without copying anything into `first', so
> slap_queue_csn crashes on the null csn. Both are element 0 of their respective
> arrays. I assume it is no surprise that syncCookie takes its value from an
> entryCSN attribute.
> To duplicate, add an entry with an explicit entryCSN, with value less than the
> current contextCSN. In my case, the entryCSN is of the format without the
> `decimal fraction' field, but I doubt that matters.
> I don't want to say OpenLDAP needs to support this, but maybe it would be better
> to catch the problem in the master, than crash the replicas.
You didn't mention how your syncrepl is configured but it seems that this can
only occur for refreshAndPersist mode, with old entries being ldapadd'd to the
running master. As you say, this is not a supported mode of operation. New data
in the server should always have a new entryCSN as well. In fact, since
entryCSN is NO-USER-MODIFICATION it shouldn't even be possible to add entries
this way to a running server. Before we can "catch the problem in the master"
we need more information on how the problem was caused.
As for crashing the replicas - the only sure solution is to patch the code in
the replicas - "catching the problem in the master" isn't really a proper
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/