Hi! The interesting point is that I added the syncrepl using ldapmodify; so why wouldn't the server reject the modification when there is a duplicate rid? If it had done so, I would have realized my mistake earlier.
Kind regards, Ulrich Windl > -----Original Message----- > From: Ondřej Kuzník <[email protected]> > Sent: Thursday, July 3, 2025 5:00 PM > To: Windl, Ulrich <[email protected]> > Cc: [email protected] > Subject: [EXT] Re: Re: Q: "monitor_back_register_entry("cn=Consumer > 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists" > > > On Thu, Jul 03, 2025 at 01:50:24PM +0000, Windl, Ulrich wrote: > > Ondřej, > > > > Good spotting! > > > > Actually I had a duplicate rid=112 in olcSyncrepl, but I never would > > have thought that monitor_back_register_entry is related to syncrepl. > > Problem was caused by a configuration script using the wrong variable... > > Hi Ulrich, > the code expects that rids are unique in a server (and documents as such), > there is nothing to check that you have complied with this requirement > but I would expect your replication might be impacted as well if you > configured it thus. > > The consumer status is also exported via cn=monitor, which had a > conflict claiming the monitor DN as you just saw. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by OpenLDAP
