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 ondra@mistotebe.net Sent: Thursday, July 3, 2025 5:00 PM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org 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