openldap-bugs September 2020

openldap-bugs@openldap.org

4 participants
300 discussions

[Issue 9340] New: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s)
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9340 Issue ID: 9340 Summary: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s) Product: OpenLDAP Version: 2.4.52 Hardware: Other OS: Solaris Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- Created attachment 761 --> https://bugs.openldap.org/attachment.cgi?id=761&action=edit Output from -d 5 option This is not a new issue, the same is observed on version 2.4.45 through 2.4.53 Setting listener-threads via slapd.conf file on Sun4v (SPARC T4-1) system to a value other than 1 results in "Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c" when starting slapd. The same does not occur when using Directory (-F) configuration. # grep '^listener-threads' /etc/openldap/slapd.conf listener-threads 8 # /usr/lib/slapd -u openldap -g openldap \ > -f /etc/openldap/slapd.conf \ > -h 'ldap:/// ldapi:/// ldaps:///' -d 5 > slapd.error 2>&1 Abort (core dumped) # tail slapd.error 5f578024 >>> dnNormalize: <cn=Current> 5f578024 <<< dnNormalize: <cn=current> 5f578024 >>> dnNormalize: <cn=Uptime> 5f578024 <<< dnNormalize: <cn=uptime> 5f578024 >>> dnNormalize: <cn=Read> 5f578024 <<< dnNormalize: <cn=read> 5f578024 >>> dnNormalize: <cn=Write> 5f578024 <<< dnNormalize: <cn=write> 5f578024 slapd starting Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c, line 903 # /usr/lib/slapd -VVV @(#) $OpenLDAP: slapd 2.4.53 (Sep 8 2020 03:15:21) $ openldap Included static overlays: accesslog auditlog collect constraint dds deref dyngroup dynlist memberof ppolicy pcache refint retcode rwm seqmod sssvlv syncprov translucent unique valsort Included static backends: config ldif monitor ldap mdb meta null passwd relay shell # When running under debugger the issue is not observed. The core file reveals the following threads: # /opt/solarisstudio12.4/bin/dbx /usr/lib/slapd core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libc.so.1 Reading libldap_r-2.4.so.2.11.1 Reading liblber-2.4.so.2.11.1 Reading libsasl2.so.3.0.0 Reading liblogin.so.3.0.0 Reading libgssapiv2.so.3.0.0 Reading libgssapi_krb5.so.2.2 Reading libkrb5.so.3.3 Reading libcom_err.so.3.0 Reading libkrb5support.so.0.1 Reading libk5crypto.so.3.1 Reading libucrypto.so.1 Reading libbsm.so.1 Reading libtsol.so.2 Reading libinetutil.so.1 Reading libcryptoutil.so.1 Reading libelf.so.1 Reading libz.so.1 Reading libresolv.so.2 Reading libkwarn.so.1 Reading libplain.so.3.0.0 Reading libotp.so.3.0.0 Reading libcrypto.so.1.0.0 Reading libsasldb.so.3.0.0 Reading libdb-5.3.so Reading libscram.so.3.0.0 Reading libltdl.so.7.3.1 Reading libssl.so.1.0.0 Reading libuuid.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0x0007fdd05cce17a8: __lwp_sigqueue+0x0008: bcc,a,pt %icc,__lwp_sigqueue+0x18 ! 0x7fdd05cce17b8 (dbx) lwps l@1 LWP suspended in uucopy() o>l@2 signal SIGABRT in __lwp_sigqueue() l@3 LWP suspended in __pollsys() l@4 LWP suspended in __pollsys() l@5 LWP suspended in __pollsys() (dbx) where current thread: t@2 =>[1] __lwp_sigqueue(0x0, 0xa00386a7d98, 0x6, 0x0, 0xffffffffffffffff, 0x0), at 0x7fdd05cce17a8 [2] raise(0x6, 0x7fdd0583ff060, 0x5, 0x5, 0x0, 0x0), at 0x7fdd05cc2af0c [3] abort(0x1, 0x1210, 0x0, 0x1000, 0x7fdd05ce3c278, 0x1a278), at 0x7fdd05cbfa144 [4] _assert(0x10005d7a8, 0x10005d7c8, 0x387, 0x9, 0x8200, 0x7fdd05ce22000), at 0x7fdd05cbfb158 [5] slapd_daemon_task(0xc4, 0xffffffffffcdb7c8, 0x100382000, 0x324800, 0x61bf4f2270, 0x100406d3c), at 0x1000c118c (dbx) lwp l@1 t@1 (l@1) stopped in uucopy at 0x7fdd05cce1d34 0x0007fdd05cce1d34: uucopy+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] uucopy(0x0, 0x7fdd0553fff10, 0xb0, 0xfffffffffffffff8, 0x0, 0xfffffe59ec25a990), at 0x7fdd05cce1d34 [2] setup_top_frame(0x7fdd054c00000, 0x7fffc0, 0x7fdd0553fffc0, 0x7fdd0553fffc0, 0x0, 0xfffffe59ec25adf0), at 0x7fdd05ccdc494 [3] setup_context(0xfffffe59ec25ab10, 0x7fdd05ccdc538, 0x7fdd058492240, 0x7fdd054c00000, 0x7fffc0, 0x1), at 0x7fdd05ccdc4dc [4] _thrp_create(0x0, 0x800000, 0x1000becb0, 0x61bfa6bed0, 0x80, 0xfffffe59ec25aeb0), at 0x7fdd05ccd7f64 [5] pthread_create(0x61bfa6bed0, 0xfffffe59ec25af78, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x0), at 0x7fdd05ccc80e4 [6] ldap_pvt_thread_create(0x61bfa6bed0, 0x0, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x61bfa6bec0), at 0x7fdd05c81b324 [7] slapd_daemon(0x100406db8, 0x4, 0x10042710c, 0x100389490, 0x100406d38, 0x100382000), at 0x1000c1404 [8] main(0x8800, 0x10038aa88, 0x1, 0x100386038, 0x1, 0x10038aa84), at 0x10009ec34 (dbx) lwp l@3 t@3 (l@3) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd0577ff2a0, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x10, 0x7fdd0577ffc30, 0x7fdd0577ff2a0, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x10, 0x7fdd0577ffc30, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x1, 0x1004010c8, 0x5), at 0x1000c014c (dbx) lwp l@4 t@4 (l@4) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd056bff370, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x12, 0x7fdd056bffd10, 0x7fdd056bff370, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x12, 0x7fdd056bffd10, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x2, 0x1004016f0, 0x5), at 0x1000c014c (dbx) lwp l@5 t@5 (l@5) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x1, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd055fff340, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x14, 0x7fdd055fffcf0, 0x7fdd055fff340, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x14, 0x7fdd055fffcf0, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x3, 0x100401d18, 0x5), at 0x1000c014c (dbx) -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9222 Bug ID: 9222 Summary: Fix presence list to use a btree instead of an AVL tree Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- [23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal [23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh [23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist [23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs [23:36] <hyc> being stored in an avl tree [23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array [23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase [00:05] <hyc> this stuff seriously needs a rewrite [01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead [01:13] <hyc> and instead it's 3-400MB -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 9354] New: Tool for monitoring slapd status
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9354 Issue ID: 9354 Summary: Tool for monitoring slapd status Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Something we've seen in various scripts many times - this tool continuously reports operation counts from cn=Monitor and tracks contextCSN from a specified baseDN, polling at the specified interval (default 10 seconds). It tracks when contextCSN changes start and stop, and for a set of multiprovider servers, reports the lag between consumers and providers. Sample output of a screen: 2020-09-21 06:25:36 ldap://tx01 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 95 108 617710 0 0 0 600000 0 0 9 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 idle contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19 ldap://tx02 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 105 120 2217678 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09 contextCSN: 20200921004548.656746Z#000000#002#000000 idle contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17 ldap://uk03 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 1407 107 675570 0 3677 0 601135 14 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14 contextCSN: 20200921004446.224575Z#000000#003#000000 idle contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33 ldap://uk04 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 98 116 2217670 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01 contextCSN: 20200921004331.841460Z#000000#004#000000 idle -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Exhausting Locked SEM_UNDO Semaphores on MacOS
by Kris Zyp 20 Oct '20

20 Oct '20

In LMDB, if you attempt to open more than 10 transactions (on different environments) on one process on MacOS, then mdb_txn_begin will fail. This can be reproduced by opening 11 different database environments in one process, and calling mdb_txn_begin (as write transactions) on each one. The 11th one will return EINVAL. I believe this is because (on this OS, MacOS 10.13.6) the System V semaphores have a limit of 10 SEM_UNDO locked semaphores on one process. So when mdb_txn_begin attempts to open an 11th transaction, the mdb_sem_wait/semop call fails, returning EINVAL. I was testing with latest LMDB from mdb.master. Once I finally debugged this and figured out the issue, I have been able to work around it by compiling with MDB_USE_POSIX_SEM which seems to resolve the issue. But this still leaves a few questions: Is there any issue with compiling with MDB_USE_POSIX_SEM on MacOS? Would it be better if LMDB defaulted to this shared lock implementation for this OS? And/or would there be value in LMDB providing a more specific error message in this situation? The documentation doesn't indicate EINVAL as a possible return value for mdb_txn_begin, and this is a very generic error with little indication of the root problem, that was rather confusing to me, at least. Or is there an expectation that processes can only open a limited number of database environments (and have open transactions on them)? (Our server typically has about 30 environments open with about 2-16 dbs/env, with many concurrent transactions, without issue on other OSes.) I would be happy to put together a patch for this, but I am not sure of the reasons for the selection of the different shared lock implementations on different OSes. Anyway, I'd be glad to help contribute a patch if there is a specific way this should work. Thank you!

2 6

[Issue 9351] New: Always build monitor, and force it to be static.
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9351 Issue ID: 9351 Summary: Always build monitor, and force it to be static. Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- With 2.5, the monitor backend should always be enabled and built as a static module rather than dynamic. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9349] New: Performance problem when trying to remove a value from an indexed attribute
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9349 Issue ID: 9349 Summary: Performance problem when trying to remove a value from an indexed attribute Product: OpenLDAP Version: 2.4.45 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: gbuades(a)soffid.com Target Milestone: --- Created attachment 762 --> https://bugs.openldap.org/attachment.cgi?id=762&action=edit Patch to improve attribute removal I have an LDAP with MDB backend, and a groupOfUniqueNames with 50.000 members. The uniqueMember attribute is indexed. When I try to remove a single user, the process takes more or less one minute to complete. After debugging, I've just found out the process to identify the old values to remove from the index is not optimum, as the time required to compare the old and the new values depends on number of values ^ 2. Taking advantage of the fact, that the values in the old and new attributes are ordered in the same way, I've build a patch to opmtimize this search process. Now, the same operation takes 0.2 seconds, when it used to take 50s. Thanks a lot for your effort, and I hope this contribution helps you and other users. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Soffid. Soffid has not assigned rights and/or interest in this work to any party. I, Gabriel Buades am authorized by Soffid, my employer, to release this work under the following terms. Soffid hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2020 Soffid Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9348] New: libldap uses deprecated symbols sys_errlist and sys_nerr
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9348 Issue ID: 9348 Summary: libldap uses deprecated symbols sys_errlist and sys_nerr Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ditu.alexandru(a)gmail.com Target Milestone: --- Starting with libc >= 2.32 the symbols sys_errlist and sys_nerr are removed: From the release notes (https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD): * The deprecated symbols sys_errlist, _sys_errlist, sys_nerr, and _sys_nerr are no longer available to newly linked binaries, and their declarations have been removed from from <stdio.h>. They are exported solely as compatibility symbols to support old binaries. All programs should use strerror or strerror_r instead. Their usage should be removed from libldap (include/ac/errno.h) and replaced with strerror or strerror_r. Otherwise any library that uses libldap compiled with libc < 2.32 won't run on systems that use newer libc versions (>= 2.32). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9346] New: test063 only supports 2 servers, should handle up to 9
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9346 Issue ID: 9346 Summary: test063 only supports 2 servers, should handle up to 9 Product: OpenLDAP Version: 2.4.52 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- And the default should be 4, as with test050 etc. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9344] New: test067-tls fails on solaris 10 due to unescaped quotes in quoted string
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9344 Issue ID: 9344 Summary: test067-tls fails on solaris 10 due to unescaped quotes in quoted string Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- This statement in test067 causes it to fail in solaris 10: TLS_PEERKEY_HASHED_FAIL="$TLS_PEERKEY_HASHALG:`echo "a fake key to hash" | \ "${openssl}" dgst "-$TLS_PEERKEY_HASHALG" -binary 2>/dev/null | \ "${openssl}" enc -base64 2>/dev/null`" Solaris10's shell requires the quotes here to be escaped, like: TLS_PEERKEY_HASHED_FAIL="$TLS_PEERKEY_HASHALG:`echo \"a fake key to hash\" | \ "${openssl}" dgst "-$TLS_PEERKEY_HASHALG" -binary 2>/dev/null | \ "${openssl}" enc -base64 2>/dev/null`" With this change the test passes -- You are receiving this mail because: You are on the CC list for the issue.

1 3

← Newer
1
2
3
4
5
6
7
8
9
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2020