RE: [EXT] Re: Re: accesslog with delta syncrepl: Why wouldn't contebnt be synced?

Hi!

I think I found some bugs in my version of OpenLDAP 2.5: First I had core-dumps when a sync was expected to happen. Like this: Mar 27 12:45:32 v06 slapd[31077]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=olcDatabase={4}mdb,cn=config on opc=0x7fa7d0001018 Mar 27 12:45:32 v06 slapd[31077]: conn=1001 op=2 syncprov_matchops: skipping relayed sid 005 Mar 27 12:45:32 v06 slapd[31077]: conn=-1 op=0 syncprov_add_slog: adding csn=20250321000000.000000Z#000000#001#000000 to sessionlog, uuid=8f32d7d8-9a95-103f-866e-d9067b62d79b Mar 27 12:45:32 v06 slapd[31077]: slap_queue_csn: queueing 0x7fa7d014e090 20250321000000.000000Z#000000#001#000000 Mar 27 12:45:32 v06 slapd[31077]: slap_graduate_commit_csn: removing 0x7fa7d014e090 20250321000000.000000Z#000000#001#000000 Mar 27 12:45:32 v06 slapd[31077]: conn=-1 op=0 accesslog_response: got result 0x44 adding log entry reqStart=20250327114532.000002Z,cn=audit Mar 27 12:45:32 v06 slapd[31077]: slap_sl_malloc of 93893629956635 bytes failed Mar 27 12:45:32 v06 systemd[1]: Created slice Slice /system/systemd-coredump. Mar 27 12:45:32 v06 systemd[1]: Started Process Core Dump (PID 31217/UID 0). Mar 27 12:45:32 v06 systemd-coredump[31218]: [🡕] Process 31077 (slapd) of user 76 dumped core.

Stack trace of thread 31081: #0 0x00007fa7fb8a941c __pthread_kill_implementation (libc.so.6 + 0xa941c) #1 0x00007fa7fb857842 raise (libc.so.6 + 0x57842) #2 0x00007fa7fb83f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007fa7fb83f4e7 __assert_fail_base.cold (libc.so.6 + 0x3f4e7) #4 0x00007fa7fb84fb32 __assert_fail (libc.so.6 + 0x4fb32) #5 0x0000555fefe6caca n/a (slapd + 0x9caca) #6 0x0000555fefe6d24e slap_sl_calloc (slapd + 0x9d24e) #7 0x0000555fefe296f4 build_new_dn (slapd + 0x596f4) #8 0x00007fa7fa8287c7 n/a (accesslog.so + 0x67c7) #9 0x00007fa7fa829182 n/a (accesslog.so + 0x7182) #10 0x0000555fefe23158 n/a (slapd + 0x53158) #11 0x0000555fefe2373c n/a (slapd + 0x5373c) #12 0x0000555fefe24294 slap_send_ldap_result (slapd + 0x54294) #13 0x0000555fefdfb823 n/a (slapd + 0x2b823) #14 0x0000555fefe87523 overlay_op_walk (slapd + 0xb7523) #15 0x0000555fefe876ae n/a (slapd + 0xb76ae) #16 0x0000555fefe76ffa n/a (slapd + 0xa6ffa) #17 0x0000555fefe7fd7d n/a (slapd + 0xafd7d) #18 0x0000555fefe13d30 n/a (slapd + 0x43d30) #19 0x00007fa7fbb10da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #20 0x00007fa7fb8a758c start_thread (libc.so.6 + 0xa758c) #21 0x00007fa7fb92ea28 __clone3 (libc.so.6 + 0x12ea28)

I'm not really surprised that "malloc of 93893629956635 bytes failed". The changelog before the error was: dn: reqStart=20250327114532.000002Z,cn=audit objectClass: auditModify reqStart: 20250327114532.000002Z reqEnd: 20250327114532.000003Z reqType: modify reqSession: 105 reqAuthzID: cn=config reqDN: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config reqResult: 0 reqMod: olcSpNoPresent:= TRUE reqMod: olcSpReloadHint:= TRUE reqMod: entryCSN:= 20250327114348.616974Z#000000#005#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20250327114348Z reqOld: olcSpNoPresent: TRUE reqOld: olcSpReloadHint: TRUE reqOld: entryCSN: 20250325081318.563987Z#000000#005#000000 reqOld: modifiersName: cn=config reqOld: modifyTimestamp: 20250325081318Z reqEntryUUID: db401792-7c0e-1032-81cf-d54356bd918f

Noticing that the objectClass is auditModify, I wonder whether the recommended filter logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" is correct.

The other bug I found is this: The reason for delta syncrepl not starting was my manual editing of the config.ldif used to slapadd: It seems a somehow non-matching contextCSN prevent delta syncrepl to start, or said the other way 'round: After I had deleted contextCSN from the config.ldif, the servers started to sync! However I had used slapadd option -w to load the data.

I don't know whether " conn=-1 op=0 syncprov_findcsn: mode=FIND_MAXCSN csn=" are related to that effect.

Kind regards, Ulrich Windl

-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Thursday, March 27, 2025 11:42 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: accesslog with delta syncrepl: Why wouldn't contebnt be synced?

On Thu, Mar 27, 2025 at 09:31:37AM +0000, Windl, Ulrich wrote:

...

Ondřej,

Still I don't quite understand: I had stopped the outdated node, deleted its accesslog, and restarted it, but still it would not sync. Then I stopped the updated node, removed the accesslog, then started it. Still the nodes would not sync. As the original node where tha data had been exported does not use delta syncrepl, I cannot import the accesslog database. So I wonder what I'll have to do to trigger a sync. To me it looks like some bug or even conceptual problem.

Hi Ulrich, I'm lost about what you're actually doing and what the actual symptoms are you're seeing. Please outline the starting point, what you did and the relevant logs from both provider and consumer in the equation.

And make sure your ACLs for both main and accesslog DBs allow unrestricted read access for the replicator user (the Admin Guide will be updated to highlight just this with the next release).

Thanks,

-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP