https://bugs.openldap.org/show_bug.cgi?id=7239
--- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 7e923c72
by OndÅ™ej KuznÃk at 2022-01-18T20:11:46+00:00
ITS#7239 Do not log internal ops
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9538
Issue ID: 9538
Summary: Accesslog entryCSN ordering is not always monotonous
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
For delta-sync replication, we rely on CSN order being preserved at all times.
When logops includes anything more than "writes", we don't use li_op_rmutex to
maintain serialisation. A concurrent write and another operation (like bind)
can have the write have its csn assigned before the bind. But before the write
finishes on the main DB and is logged, the bind has already hit accesslog.
This entry out of order doesn't match the usual filter, so non-persist sessions
will not notice, however running persist sessions could get a new cookie sent,
depending on how things are ordered when they hit syncprov.
A sample:
---- 8< ----
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD
dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com"
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on
opc=0x7d3d2800dc50
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated
new csn=20210426195604.556053Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" method=128
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0
qtime=0.005874 etime=0.015182 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated
new csn=20210426195604.558683Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80
20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on
opc=0x561f0900fcf0
Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x561f09113f80 20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0
qtime=0.000020 etime=0.004297 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148250 20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148f60 20210426195604.556053Z#000000#002#000000
---- 8< ----
Example entries in the order slapcat sees them:
---- 8< ----
dn: reqStart=20210426195604.000364Z,cn=accesslog
objectClass: auditBind
reqStart: 20210426195604.000364Z
reqEnd: 20210426195604.000365Z
reqType: bind
entryCSN: 20210426195604.558683Z#000000#002#000000
dn: reqStart=20210426195604.000351Z,cn=accesslog
objectClass: auditAdd
reqStart: 20210426195604.000351Z
reqEnd: 20210426195604.000366Z
reqType: add
entryCSN: 20210426195604.556053Z#000000#002#000000
---- 8< ----
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7080
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• 2bf59ff6
by OndÅ™ej KuznÃk at 2022-01-06T03:05:45+00:00
ITS#7080 Find config entry before processing pre-read on delete
RE26:
• cf2a4a60
by OndÅ™ej KuznÃk at 2022-01-12T22:38:11+00:00
ITS#7080 Find config entry before processing pre-read on delete
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9768
Issue ID: 9768
Summary: slapo-translucent handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcTranslucentLocal/olcTranslucentRemote is passed multiple attribute names
in a single value that (or one further down the list) is later removed, the
overlay doesn't handle its removal correctly. We should encourage users to
provide a single attribute name per value, just like we do in EMIT for those
provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9767
Issue ID: 9767
Summary: slapo-unique handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcUniqueIgnore/olcUniqueAttribute is passed multiple names in a single
value that is later removed, the overlay doesn't handle its removal correctly.
We should encourage users to provide a single attribute name per value, just
like we do in EMIT for those provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9556
Issue ID: 9556
Summary: slapd-config should return invalidAttributeSyntax if
parsing schema description fails
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
I'm currently testing error handling and interacting with LDAP clients (e.g. my
web2ldap).
Sending an invalid attribute type description results in an error (as expected)
returned by slapd-config:
RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes:
Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
But result code other(80) seems not very useful. It's too unspecific to decide
on specific error handling.
It would be much more useful if slapd-config returns invalidAttributeSyntax(21)
in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9576
Issue ID: 9576
Summary: Add ConfigTable link into ConfigArgs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Would make it possible to examine defaults if necessary.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9729
Issue ID: 9729
Summary: Allow setting multiprovider before adding syncrepl
stanzas
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
It should be possible to set multiprovider first, avoiding the window of the DB
being read-only while performing an online upgrade of a single provider to an
MPR set up and generally simplifying configuration.
Instead, the only requirement should be that serverID has been explicitly set
(hopefully != 0).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6097
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.2 |2.6.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9778
Issue ID: 9778
Summary: Can't find the back-xxx.la libraries
Product: OpenLDAP
Version: 2.6.0
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: burt.stampfl(a)amsc.com
Target Milestone: ---
Created attachment 870
--> https://bugs.openldap.org/attachment.cgi?id=870&action=edit
Output from the build steps I described in the 'description' above.
Hi, I'm new to OpenLDAP.
Pulled down the current 2.6 release to a Debian target and am having trouble
figuring out how to build the backend modules for dynamic use.
What I did:
1. Downloaded openldap-2.6.0.tgz and extracted the source on my Debian target.
2. configured the 'build' via (output indicated it was successful) :
./configure --enable-sql=no --enable-wt=no --enable-spasswd=yes
--enable-passwd=yes --enable-perl=yes --enable-crypt=yes --enable-ldap=yes
--enable-slapd=yes --enable-ppolicy=yes --enable-otp=yes --enable-auditlog=yes
--enable-modules=yes --with-cyrus-sasl=yes
3. ran 'make depend' (output indicated it was successful).
4. ran 'make' (output indicated it was successful).
5. ran the tests via 'env SLAPD_DEBUG=1 make test' (output indicated it was
successful).
6. Installed it via 'su root -c 'make install'
I was able to pretty easily get the slapd server running, create a database
(mdb) add users, etc, and access via a remote client.
Once I was able to do that I wanted to enable the ppolicy backend/overlay and
have not been able to get this to work. Looking online it appears I need some
'backend' modules like back-mdb.la, ppolicy.la, etc and I cannot find them
anywhere in my build tree. I had thought the --enable-xxx directives I used in
the config step would have forced this to build them, but I guess not.
How do I create these dynamic backend modules and is there any documentation on
how to use them in the newer dynamic configuration schema ?
I've attached a file with the output from the steps I performed above.
Thank you
Burt
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INVALID
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
--- Comment #23 from Howard Chu <hyc(a)openldap.org> ---
> Running slapadd to build slapd database...
../../../libraries/liblmdb/mdb.c:7544:26: runtime error: member access within
misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8
byte alignment
0x0000023fe67a: note: pointer points here
00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00
00 00 00 00 00 00 00
The code in question is accessing an unsigned short on a 2 byte boundary. I.e.,
its alignment is correct. UBsan is incorrect here.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9775
Issue ID: 9775
Summary: fresh git clone will not build
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: nick(a)folino.us
Target Milestone: ---
git clone https://git.openldap.org/openldap/openldap.git
cd openldap
./configure
make depend
Entering subdirectory tests
make[1]: Entering directory 'openldap/tests'
Making depend in openldap/tests
Entering subdirectory modules
make[2]: Entering directory 'openldap/tests/modules'
make[2]: *** No rule to make target 'depend'. Stop.
make[2]: Leaving directory 'openldap/tests/modules'
make[1]: *** [Makefile:430: depend-common] Error 1
make[1]: Leaving directory 'openldap/tests'
make: *** [Makefile:356: depend-common] Error 1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9774
Issue ID: 9774
Summary: Add and maintain file CHANGES for 2.6.x
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
In opposite to rel eng branches for 2.4.x and 2.5.x the branch for 2.6.x is
still missing a CHANGES files.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9773
Issue ID: 9773
Summary: slapo-allowed should also list "operational"
attributes
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
When using slapo-allowed a client may disable input fields for attributes not
listed in 'allowedAttributesEffective'. This helps the user to understand that
he/she should not even try to modify the attribute (better UX).
But slapo-allowed never shows operational attributes in
allowedAttributesEffective. In most use-cases this is understandable but there
are some nice use-cases (e.g. setting pwdPolicySubentry) where it should be
possible for the client to display an enabled input field even for operational
attributes.
See also:
* Discussion in ITS#9671
* https://code.stroeder.com/ldap/web2ldap/issues/24
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9769
Issue ID: 9769
Summary: Patch new feature batch get
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: rouzier(a)gmail.com
Target Milestone: ---
Created attachment 859
--> https://bugs.openldap.org/attachment.cgi?id=859&action=edit
New functionality mdb_cursor_get_batch
New functionality mdb_cursor_get_batch
mdb_cursor_get_batch retrieves a page worth of key/values.
This is to reduce the number of function calls when doing a scan of the
database.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
--- Comment #22 from noloader(a)gmail.com <noloader(a)gmail.com> ---
On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote:
>
> noloader(a)gmail.com wrote:
> > On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote:
> >>
> >> noloader(a)gmail.com wrote:
> >> ...
> >>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an
> >>> important project, and the undefined behavior is causing too many
> >>> tangential problems.
> >>
> >> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary
> >> part of the language for its intended use as a system programming language, writing
> >> machine-specific programs. Anyone who says it is prohibited by the spec is wrong.
The kernel recently got bitten using the same pattern of unaligned
short pointers through casts. GCC produced code which corrupted
initramfs during unpacking.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363.
OpenLDAP should fix that code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9493
Issue ID: 9493
Summary: slapo-accesslog handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: svella(a)technologist.com
Target Milestone: ---
I observed this in the debugger while working on a small feature addition to
slapo-accesslog.
log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr
(accesslog.c:989), linked list li_oldattrs is being built by inserting each
value in order at the head of the list, resulting in the list being in reverse
order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989),
it is using the index of the removed value (valx) to find and removed the entry
in the linked list, but it's counting from the head of li_oldattrs and not the
tail, resulting in the wrong item being removed from the list unless counting
from the head or the tail happens find the same item.
(Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76)
Handling of oldAccessLogBase appears to have the same problem, and a cursory
glance through the source of other overlays reveals a similar pattern, and I'm
guessing the same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9765
Issue ID: 9765
Summary: slapd crash
Product: OpenLDAP
Version: 2.4.46
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: shivaprasadtp(a)yahoo.in
Target Milestone: ---
Start-up two slapd server instances. Configure syncreply overlay with one of
the servers as a provider and the other one as consumer. Create around 100
users. Now start changing syncrepl configuration for one of the slapd servers,
lets say the consumer server, in a loop with 5 seconds delay. After few mins
the slapd server crashes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9757
Issue ID: 9757
Summary: The private key of the ldap certificate
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ydgdsnn(a)163.com
Target Milestone: ---
Created attachment 856
--> https://bugs.openldap.org/attachment.cgi?id=856&action=edit
prikey.key
Current situation: The private key of the ldap certificate is used to set
LDAP_OPT_X_TLS_KEYFILE when bind, and this file is currently stored in plain
text.
Appeal: Can we store the ciphertext of the file, and then decrypt it when we
use it?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8485
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ydgdsnn(a)163.com
--- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 9757 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9754
Issue ID: 9754
Summary: segfault after adding olcAccess
Product: OpenLDAP
Version: 2.6.0
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: goudal(a)enseirb.fr
Target Milestone: ---
On a new production server 2.6.0 on ubuntu 20.04 LTS uptodate.
After adding an olcAccess attribute I got a segfault.
The aclValue added is
{9}to attrs=ipbCompteValide,ipbEtendue,mailForwardingAddress by
dn.base="uid=cptadmin,ou=people,dc=ipb,dc=fr" write by * read
(the ipbXXX attrs are local ones).
I have tried to add it twice and it did segfault twice.
Here are the last logs for the server (logLevel was on sync).
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_graduate_commit_csn: removing
0x7f3a475615c0 20211125133351.609580Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 MOD
dn="dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 MOD attr=contextCSN
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 syncprov_matchops:
recording uuid for dn=dc=ipb,dc=fr on opc=0x7f3a48001440
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1053 op=1 syncprov_qresp: set up a
new syncres mode=2 csn=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 RESULT tag=103 err=0
qtime=0.000017 etime=0.003762 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SRCH
base="dc=ipb,dc=fr" scope=2 deref=0
filter="(entryUUID=29a4991c-9dda-103b-98c2-c3fe49d4fff9)"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SRCH attr=* +
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SEARCH RESULT
tag=101 err=0 qtime=0.000028 etime=0.000285 nentries=1 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 MOD
dn="uid=pbouchevrea,ou=people,dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 MOD attr=ipbDateFin
entryCSN modifiersName modifyTimestamp
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 syncprov_matchops:
recording uuid for dn=uid=pbouchevrea,ou=people,dc=ipb,dc=fr on
opc=0x7f3a48001630
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 syncprov_findbase:
searching
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_queue_csn: queueing 0x7f3a438bc700
20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1053 op=1 syncprov_qresp: set up a
new syncres mode=2 csn=20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 RESULT tag=103 err=0
qtime=0.000025 etime=0.022224 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_graduate_commit_csn: removing
0x7f3a438bc700 20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 MOD
dn="dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 MOD attr=contextCSN
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 syncprov_matchops:
recording uuid for dn=dc=ipb,dc=fr on opc=0x7f3a50003440
Nov 25 14:34:32 ldap2021 kernel: [262778.995540] slapd[68072]: segfault at 0 ip
00007f4ea0d3553e sp 00007f4e9dae9f48 error 4 in
libc-2.31.so[7f4ea0cad000+178000]
Nov 25 14:34:32 ldap2021 kernel: [262778.995584] Code: b6 07 29 c8 c3 0f 1f 80
00 00 00 00 f3 0f 1e fa 89 f8 31 d2 66 0f ef ff 09 f0 25 ff 0f 00 00 3d c0 0f
00 00 0f 8f 74 02 00 00 <f3> 0f 6f 0f f3 0f 6f 06 66 0f 74 c1\
66 0f da c1 66 0f ef c9 66 0f
Nov 25 14:34:36 ldap2021 slapd[70083]: * Stopping OpenLDAP slapd
--
You are receiving this mail because:
You are on the CC list for the issue.