Q: "monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists"
Hi!
For openldap-2.5 and an MMR configuration I see the message monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists during startup. I'm wondering what the messages actually says, and what causes it. Could it be some bug in OpenLDAP? The machine in question is real hardware (no VM) and it has a *lot* of RAM (500G) and CPUs (64).
If I query the monitoring database, I see no such connection.
Kind regards, Ulrich Windl
On Thu, Jul 03, 2025 at 06:51:21AM +0000, Windl, Ulrich wrote:
Hi!
For openldap-2.5 and an MMR configuration I see the message monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists during startup. I'm wondering what the messages actually says, and what causes it. Could it be some bug in OpenLDAP? The machine in question is real hardware (no VM) and it has a *lot* of RAM (500G) and CPUs (64).
Hi Ulrich, are you sure you're not using duplicate rid= values in your configuration?
Regards,
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...
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Thursday, July 3, 2025 11:14 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Q: "monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists"
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
On Thu, Jul 03, 2025 at 06:51:21AM +0000, Windl, Ulrich wrote:
Hi!
For openldap-2.5 and an MMR configuration I see the message monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists during startup. I'm wondering what the messages actually says, and what causes it. Could it be some bug in OpenLDAP? The machine in question is real hardware (no VM) and it has a *lot* of RAM (500G) and CPUs (64).
Hi Ulrich, are you sure you're not using duplicate rid= values in your configuration?
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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,
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
On Fri, Jul 04, 2025 at 06:29:08AM +0000, Windl, Ulrich wrote:
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.
As I said, the configuration code doesn't (currently) detect this, but it will cause you problems later on.
openldap-technical@openldap.org
-
Ondřej Kuzník -
Windl, Ulrich