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 <[email protected]>
> Sent: Thursday, March 27, 2025 11:42 AM
> To: Windl, Ulrich <[email protected]>
> Cc: [email protected]
> 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
