[Issue 10440] New: memberof stop working on replication slaves after upgrade from 2.6.10
https://bugs.openldap.org/show_bug.cgi?id=10440
Issue ID: 10440 Summary: memberof stop working on replication slaves after upgrade from 2.6.10 Product: OpenLDAP Version: 2.6.12 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: statoon54@gmail.com Target Milestone: ---
Hi, We encountered a problem yesterday when upgrading to OpenLDAP version 2.6.12.1 from 2.6.10.1. The memberOf overlay failed to delete or add memberOf on the replica servers. Replication is functioning correctly, memberOf on master works too, but adding or removing a group member from the master no longer triggers this change on the slave servers. I think there's a regression in this version when replication occurs.
Standard configuration overlay memberof memberof-refint true memberof-dangling ignore
# sortVals sortvals member
# multivalued attributes stockage improvement multival member 1000,100
# # Sync prov Replica #
# syncrepl directive syncrepl rid=001 provider=""xxxxxx" bindmethod=simple binddn="xxxxxx" credentials="xxxxx" searchbase="xxxxx" scope="sub" attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 12 60 10 300 24 3600 +" timeout=60 network-timeout=0 keepalive=0:0:0
updateref xxxxxx
---
Some trace show a 122 failed on memberof_value_modify if i add or delete a member. (works great since 2.6.10 on slaves)
févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260204103803.030751Z#000000#000#000000 tid 0x7f7a1d3fd6c0 févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 be_search (0) févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing 0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: conn=-1 op=0: memberof_value_modify DN="uid=269015,ou=accounts,dc=exemple,dc=fr" delete memberOf="cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr" failed err=122 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn: removing 0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001 be_modify cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr (0) févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing 0x7f7a14439de0 20260204103803.030751Z#000000#000#000000 févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn: removing 0x7f7a14439de0 20260204103803.030751Z#000000#000#000000
https://bugs.openldap.org/show_bug.cgi?id=10440
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6916, | |https://bugs.openldap.org/s | |how_bug.cgi?id=10358
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Hi, thanks for the report.
On the surface this looks like a victim of ITS#10358 but more importantly it is probably related to ITS#6916 in general overlays just copy the incoming Operation without considering any controls that might be attached to it already and it might not just be memberof that's the culprit here.
https://bugs.openldap.org/show_bug.cgi?id=10440
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs@openldap.org |ondra@mistotebe.net
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- I've fixed the overlays I could find that do this: https://git.openldap.org/openldap/openldap/-/merge_requests/830
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #3 from jrautureau@gmail.com --- Hello everybody
same regression here where our 2 slaves (container) have been unresponsive and not working at all.
memberOf not synced and others issues
rollback to 2.6.10 fixes the problem.
can't wait to have the 2.6.13 version
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #4 from Ondřej Kuzník ondra@mistotebe.net --- On Thu, Feb 05, 2026 at 08:32:33PM +0000, openldap-its@openldap.org wrote:
same regression here where our 2 slaves (container) have been unresponsive and not working at all.
memberOf not synced and others issues
Hi, please be specific about "other issues", possibly opening an ITS for them with accompanying information. We can't fix what doesn't get reported ;)
rollback to 2.6.10 fixes the problem.
can't wait to have the 2.6.13 version
If you can confirm issues are (not?) resolved with the patch(es) in MR!830[0], that would also be nice to know.
[0]. https://git.openldap.org/openldap/openldap/-/merge_requests/830
Thanks,
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #5 from statoon54@gmail.com --- Hi Ondřej,
I confirm that the issue is resolved with your patch. No more member_op in the trace. And add & delete member from a group works as usual with memberof overlay.
Thank you for this resolution.
2026-02-06T14:00:33.669692+01:00 ldap-v4-slave-1-dev slapd[824891]: do_syncrep2: rid=001 cookie=rid=001,csn=20260206130033.205923Z#000000#000#000000 2026-02-06T14:00:33.673989+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_message_to_entry: rid=001 DN: cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr, UUID: b791fb76-8a1a-1040-927a-2905174a27a4 2026-02-06T14:00:33.674029+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260206130033.205923Z#000000#000#000000 tid 0x7f6e9b9fe6c0 2026-02-06T14:00:33.675792+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_search (0) 2026-02-06T14:00:33.676985+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr 2026-02-06T14:00:33.677507+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c12bbe0 20260206130033.205923Z#000000#000#000000 2026-02-06T14:00:33.752498+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c12bbe0 20260206130033.205923Z#000000#000#000000 2026-02-06T14:00:33.752819+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_modify cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr (0) 2026-02-06T14:00:33.752929+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c12b440 20260206130033.205923Z#000000#000#000000 2026-02-06T14:00:33.758033+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c12b440 20260206130033.205923Z#000000#000#000000 2026-02-06T14:01:12.717155+01:00 ldap-v4-slave-1-dev slapd[824891]: do_syncrep2: rid=001 cookie=rid=001,csn=20260206130112.481983Z#000000#000#000000 2026-02-06T14:01:12.717362+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_message_to_entry: rid=001 DN: cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr, UUID: b791fb76-8a1a-1040-927a-2905174a27a4 2026-02-06T14:01:12.719014+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260206130112.481983Z#000000#000#000000 tid 0x7f6e9b9fe6c0 2026-02-06T14:01:12.719059+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_search (0) 2026-02-06T14:01:12.720923+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr 2026-02-06T14:01:12.721036+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c1298b0 20260206130112.481983Z#000000#000#000000 2026-02-06T14:01:13.408575+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c1298b0 20260206130112.481983Z#000000#000#000000 2026-02-06T14:01:13.408848+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_modify cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr (0) 2026-02-06T14:01:13.410122+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c129520 20260206130112.481983Z#000000#000#000000 2026-02-06T14:01:13.410648+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c129520 20260206130112.481983Z#000000#000#000000 2026-02-06T14:02:10.518835+01:00 ldap-v4-slave-1-dev slapd[824891]: do_syncrep2: rid=001 cookie=rid=001,csn=20260206130210.412428Z#000000#000#000000 2026-02-06T14:02:10.521497+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_message_to_entry: rid=001 DN: cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr, UUID: b791fb76-8a1a-1040-927a-2905174a27a4 2026-02-06T14:02:10.523789+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260206130210.412428Z#000000#000#000000 tid 0x7f6e9b9fe6c0 2026-02-06T14:02:10.525131+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_search (0) 2026-02-06T14:02:10.526552+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr 2026-02-06T14:02:10.526589+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c121180 20260206130210.412428Z#000000#000#000000 2026-02-06T14:02:10.549554+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c121180 20260206130210.412428Z#000000#000#000000 2026-02-06T14:02:10.549613+01:00 ldap-v4-slave-1-dev slapd[824891]: syncrepl_entry: rid=001 be_modify cn=APP:ESUP-EMARGEMENT,ou=groups,dc=exemple,dc=fr (0) 2026-02-06T14:02:10.549643+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_queue_csn: queueing 0x7f6e8c120dd0 20260206130210.412428Z#000000#000#000000 2026-02-06T14:02:10.552868+01:00 ldap-v4-slave-1-dev slapd[824891]: slap_graduate_commit_csn: removing 0x7f6e8c120dd0 20260206130210.412428Z#000000#000#000000
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #6 from David Coutadeur david.coutadeur@gmail.com ---
Hello,
As a maintainer of OpenLDAP-LTB, I noticed that many customers were impacted by this issue. Thanks for the quick patch!
Do you plan to release a version 2.6.13 soon for deploying the fix widely?
Regards
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #7 from Ondřej Kuzník ondra@mistotebe.net --- On Fri, Feb 06, 2026 at 01:37:47PM +0000, openldap-its@openldap.org wrote:
Hello,
As a maintainer of OpenLDAP-LTB, I noticed that many customers were impacted by this issue. Thanks for the quick patch!
Do you plan to release a version 2.6.13 soon for deploying the fix widely?
Hi David, the project will have a call on Tuesday reviewing what happened with 2.6.11/12 and my assumption is a next testing call will be issued shortly after at the latest. Where that puts the next release will be decided there as well.
Regards,
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #8 from David Coutadeur david.coutadeur@gmail.com --- Hi,
Ok, thanks for clarifying that!
Regards, David
https://bugs.openldap.org/show_bug.cgi?id=10440
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.13 Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=10440
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FEEDBACK Status|IN_PROGRESS |RESOLVED
--- Comment #9 from Quanah Gibson-Mount quanah@openldap.org --- head:
• 15dac6f4 by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-autogroup: do not propagate request controls to internal ops
• 663d9569 by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-constraint: do not propagate request controls to internal ops
• 73a97a77 by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-memberof: do not propagate request controls to internal ops
• 04ebe9ab by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-nestgroup: do not propagate request controls to internal ops
• 813cf829 by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-retcode: do not propagate request controls to internal ops
• 92762941 by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-syncprov: do not propagate request controls to internal ops
• 5129517b by Ondřej Kuzník at 2026-02-10T16:54:48+00:00 ITS#10440 slapo-retcode: do not propagate request controls to internal ops
https://bugs.openldap.org/show_bug.cgi?id=10440
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FEEDBACK |TEST
--- Comment #10 from Quanah Gibson-Mount quanah@openldap.org --- RE26:
• b2966738 by Ondřej Kuzník at 2026-02-13T02:26:09+00:00 ITS#10440 slapo-autogroup: do not propagate request controls to internal ops
• 546c8850 by Ondřej Kuzník at 2026-02-13T02:26:15+00:00 ITS#10440 slapo-constraint: do not propagate request controls to internal ops
• 3307d60c by Ondřej Kuzník at 2026-02-13T02:26:21+00:00 ITS#10440 slapo-memberof: do not propagate request controls to internal ops
• 1f5d32a2 by Ondřej Kuzník at 2026-02-13T02:26:26+00:00 ITS#10440 slapo-nestgroup: do not propagate request controls to internal ops
• 2122bc08 by Ondřej Kuzník at 2026-02-13T02:26:32+00:00 ITS#10440 slapo-retcode: do not propagate request controls to internal ops
• c2fd8cc9 by Ondřej Kuzník at 2026-02-13T02:26:37+00:00 ITS#10440 slapo-syncprov: do not propagate request controls to internal ops
• 3f35c3c8 by Ondřej Kuzník at 2026-02-13T02:26:43+00:00 ITS#10440 slapo-retcode: do not propagate request controls to internal ops
https://bugs.openldap.org/show_bug.cgi?id=10440
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED
https://bugs.openldap.org/show_bug.cgi?id=10440
--- Comment #11 from ccnx@qq.com --- 已收到您的邮件。(自动回复)
-
openldap-its＠openldap.org