[Date Prev][Date Next] [Chronological] [Thread] [Top]

Issue in syncprov findcsn code

Not sure this is a bug, but I'm curious... I hit this while checking for ITS#5661. The code below is from HEAD's syncprov.c:613 (not changed recently; pardon any unintended line wrapping):

switch( mode ) {
cf.f_choice = LDAP_FILTER_GE;
/* If there are multiple CSNs, use the one with our serverID */
for ( i=0; i<si->si_numcsns; i++) {
if ( slap_serverID == si->si_sids[i] ) {
maxid = i;

When run by a consumer, with no serverID set (and thus slap_serverID == 0), it causes the consumer to use the contextCSN with SID == "000" instead of the most recent one. As a consequence, if one searches the contextCSN within that consumer, slapo-syncprov's syncprov_operational() causes only that value to be returned, instead of all contextCSNs. After the consumer is restarted, all values are correctly returned. To reproduce:

- populate a DSA (SIDs in CSNs will default to "000")

- turn it into a (multi)master by adding the serverID statement (with SID > "000") and so

- perform a modification (so that the most recent contextCSN will have SID != "000")

- create a consumer (no serverID statement, so that it defaults to "000") and let it pull data from the producer

- search the contextCSN of the consumer

I'm not sure this is a bug; it might be harmless, apart from being definitely misleading. There might be multiple solutions:

- don't let syncprov_operational() muck with contextCSN that way

- make syncprov_findcsn() search the newest contextCSN instead of the one with its SID

- initialize slapd_serverID with some SID_UNDEFINED in order to take the action above only when SID is not defined


Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it