https://bugs.openldap.org/show_bug.cgi?id=9705
--- Comment #1 from Howard Chu <[email protected]> --- Eugeny Gil wrote: > > Hi guys, > > > > > > > > There is an issue with syncrepl and syncprov working together in parallel. > > The issue can be seen in provider LDAP server logs of > > test059-consumer-config. For > > linux this problem does not cause the test to malfunction, but it may cause > > replication to malfunction on other systems (or possibly on linux in a > > different > > situation from the test). In case of OpenVMS we have this issue. > > > > > > > > The problem is detected under the following circumstances, followed by a > > step-by-step description of the actions in test 059 that lead to > > malfunction: I cannot comment on your actual problem, but your analysis is incorrect. > > this registers new syncInfo structure with the parameter rid=002 inside the > > syncrepl engine. Should also be added info into cookies of this structure > > but this > > is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the > > cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is > > overrides by > > this new cookie data. It can be seen in provider server logs (was run on > > linux): That is not what the logs say. > > …… > > > > 61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer" > > > > 61275c7d oc_check_required entry > > (olcDatabase={1}mdb,cn=config,cn=consumer), objectClass "olcMdbConfig" > > > > …… > > > > 61275c7d slap_get_csn: conn=1007 op=3 generated new > > csn=20210826091853.649104Z#000000#001#000000 manage=1 > > > > 61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0 > > 20210826091853.649104Z#000000#001#000000 > > > > 61275c7d ldif_write_entry: wrote entry > > "olcDatabase={1}mdb,cn=config,cn=consumer" > > > > 61275c7d ldif_back_add: err: 0 text: > > > > 61275c7d send_ldap_result: conn=1007 op=3 p=3 > > > > 61275c7d send_ldap_result: err=0 matched="" text="" > > > > 61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for > > dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608 > > > > …… > > > > 61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0 > > 20210826091853.649104Z#000000#001#000000 > > > > 61275c7d conn=1004 op=1 syncprov_sendresp: > > cookie=*rid=001*,sid=001,csn=20210826091853.649104Z#000000#001#000000 > > > > 61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD, > > dn=olcDatabase={1}mdb,cn=config,cn=consumer > > > > …… > > rid=002 should be there! No. The rid identifies a consumer. If you search back in your log for the operations on conn=1004 in this case, you'll see that the consumer on that connection used rid=001, therefore rid=001 is what must be sent back to it. Whatever other problem you may be seeing, this log snippet is not evidence of any bug. -- You are receiving this mail because: You are on the CC list for the issue.
