[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9337
Issue ID: 9337
Summary: Slapd crash with lastbind overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: frederic.poisson(a)admin.gmessaging.net
Target Milestone: ---
Hello,
I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1
master and 1 replica), and when i activate the lastbind overlay. The replica
server crash like this :
slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in
slapd[400000+1d8000]
The database is this one with overlay loaded :
dn: cn=module{0},cn=config
olcModuleLoad: {0}sssvlv.la
olcModuleLoad: {1}ppolicy.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}lastbind.la
olcModuleLoad: {4}pw-sha2.la
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcUpdateRef: ldap://master.server:389/
If i add this configuration it crash :
dn: olcOverlay={2}lastbind
objectClass: olcOverlayConfig
objectClass: olcLastBindConfig
olcOverlay: {2}lastbind
olcLastBindPrecision: 60
olcLastBindForwardUpdates: TRUE
Does the release 2.5.51 or 2.5.52 could solve this issue ?
Regards,
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9382] New: client tools ldapvc.c tracks criticality but doesn't use it
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9382
Issue ID: 9382
Summary: client tools ldapvc.c tracks criticality but doesn't
use it
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In clients/toolsldapv.c, we have:
switch ( i ) {
char *control, *cvalue;
int crit;
...
case 'E': /* vc extension */
crit = 0;
if( optarg[0] == '!' ) {
crit = 1;
and then we never use "crit" again. It would appear the intention was to
determine whether or not this control is marked critical and then do something
based on that, but there is in fact nothing ever done.
This leads to a warning that crit is set but unused.
If the criticality of the control doesn't matter, than this variable should be
eliminated. If it does matter, then the missing code needs to be added.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 8 months
[Issue 9288] New: slapd service stops suddenly but generates crash file
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9288
Issue ID: 9288
Summary: slapd service stops suddenly but generates crash file
Product: OpenLDAP
Version: 2.4.49
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tekkitan(a)gmail.com
Target Milestone: ---
System: t3.small AWS instance 2VCPU 2GB RAM
OS: Ubuntu 20.04 (was happening on 16.04 as well)
Package Version: 2.4.49+dfsg-2ubuntu1.2
We've been having this weird problem with slapd between Ubuntu 16.04 and Ubuntu
20.04 where slapd will suddenly stop according to syslog but will also generate
a crash file within apport. We thought it was due to some weird stuff we were
doing in the 16.04 version (2.4.42+dfsg-2ubuntu3.8), but we deployed a new LDAP
proxy in 20.04 (2.4.49+dfsg-2ubuntu1.2) which appears to have the same issue so
I am reporting it and hoping for guidance as we use this proxy for our
corporate VPN.
Below is the backtrace which was the same from both proxy systems, but this one
is from the 20.04 version as that is our current system in use:
root@useldap02:~/_usr_sbin_slapd.0.crash# apport-retrace --stdout
/var/crash/_usr_sbin_slapd.0.crash
--- stack trace ---
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 140488162916432, 140488307736576, 140487911640016,
140487911640117, 140487911640016, 140487911640016, 140487911640147,
140487911640316, 140487911640016, 140487911640316, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007fc5f3043859 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x2, sa_sigaction = 0x2},
sa_mask = {__val = {131, 4, 99, 0, 0, 140488164070405, 0, 21474836480,
140488121483504, 0, 140488164102160, 0, 6703301646461552640, 140488164070405,
140488165695488, 140488164087176}}, sa_flags = -235332728, sa_restorer = 0xbf}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007fc5f3043729 in __assert_fail_base (fmt=0x7fc5f31d9588 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=0x7fc5f1f91953
"!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88
"../../../../../servers/slapd/back-ldap/bind.c", line=191, function=<optimized
out>) at assert.c:92
str = 0x7fc5c410a280 "@Q\021\344\305\177"
total = 4096
#3 0x00007fc5f3054f36 in __GI___assert_fail (assertion=0x7fc5f1f91953
"!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88
"../../../../../servers/slapd/back-ldap/bind.c", line=191,
function=0x7fc5f1f921a0 "ldap_back_conn_delete") at assert.c:101
No locals.
#4 0x00007fc5f1f807c7 in ldap_back_conn_delete () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#5 0x00007fc5f1f814a4 in ?? () from /usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#6 0x00007fc5f1f815ad in ldap_back_release_conn_lock () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#7 0x00007fc5f1f833bc in ldap_back_retry () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#8 0x00007fc5f1f7ec0b in ldap_back_search () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#9 0x000055b87105cc88 in overlay_op_walk ()
No symbol table info available.
#10 0x000055b87105cdb7 in ?? ()
No symbol table info available.
#11 0x000055b870fef80d in fe_op_search ()
No symbol table info available.
#12 0x000055b870fef034 in do_search ()
No symbol table info available.
#13 0x000055b870fec6ed in ?? ()
No symbol table info available.
#14 0x000055b870fed22c in ?? ()
No symbol table info available.
#15 0x00007fc5f32e7a03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2
No symbol table info available.
#16 0x00007fc5f3219609 in start_thread (arg=<optimized out>) at
pthread_create.c:477
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140488121493248,
-8220430158823943899, 140488129874654, 140488129874655, 140488129874784,
140488121490880, 8241811018110734629, 8241811687867814181}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call = 0
#17 0x00007fc5f3140103 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
This is usually what we see within syslog when slapd stops:
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH
base="ou=people,dc=company,dc=com" scope=2 deref=0
filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))"
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH attr=cn uid sn
mail proxyAddresses userPrincipalName fullName displayName description
objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day
fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl
fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod
fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods
fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods
fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret
fw1ISAKMP-DataEncMethod givenName surname
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH
base="ou=groups,dc=company,dc=com" scope=2 deref=0
filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))"
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH attr=cn uid sn
mail proxyAddresses userPrincipalName fullName displayName description
objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day
fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl
fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod
fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods
fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods
fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret
fw1ISAKMP-DataEncMethod givenName surname
Jul 11 00:49:34 useldap02 slapd[28099]: * Stopping OpenLDAP slapd
Jul 11 00:49:34 useldap02 slapd[28099]: ...done.
Jul 11 00:49:34 useldap02 systemd[1]: slapd.service: Succeeded.
Note that a lot of these attributes being searched for (all the fw1*
attributes) do not exist within our LDAP. Not sure if that would be the cause.
Thank you for any help that can be provided.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 8 months
[Issue 9270] New: Admin guide: Add detailed information on indexing
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9270
Issue ID: 9270
Summary: Admin guide: Add detailed information on indexing
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
It would be useful to outline what the different types of indexing options do,
and when they are useful, in the admin guide.
For example:
presence indexing is only useful if looking to find entries with a given
attribute, when generally < 50% of the entries in the DB have an instance of
that attribute.
equality indexing would not be particularly useful on an attribute that exists
in most every entry, and the attribute always has the same value
etc.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 8 months
[Bug 9260] New: slapd-ldap(5) man page missing conn-pool-max option
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9260
Bug ID: 9260
Summary: slapd-ldap(5) man page missing conn-pool-max option
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The slapd-ldap(5) man page is missing any information on the conn-pool-max
configuration option.
Part of ITS#4791
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 8 months
[Bug 9241] New: olcRefintNothing refuse to accept space in the target dn
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9241
Bug ID: 9241
Summary: olcRefintNothing refuse to accept space in the target
dn
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: sebastien.chaumat(a)qspin.be
Target Milestone: ---
When configuring refint :
dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: {2}refint
olcRefintAttribute: seeAlso
olcRefintNothing: cn=admin,dc=test
is accepted
but
olcRefintNothing: cn=admin space,dc=test
is rejected when I ldapadd the configuration with the message :
ldap_add: Constraint violation (19)
additional info: <olcRefintNothing> extra cruft after <string>
I tried various quoting :
cn="admin space",dc=test
cn=admin\20space
"cn=admin space"
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 8 months
[Issue 9325] New: Expand SSL test suite for multiple EC support and SAN checks
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9325
Issue ID: 9325
Summary: Expand SSL test suite for multiple EC support and SAN
checks
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: ---
Need to expand the TLS test suite with some additional certs and EC support to
ensure proper testing of issue#9054 and issue#9318
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 8 months
[Bug 9199] New: Disable IPv6 makes listener work on IP address but hostname or localhost
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9199
Bug ID: 9199
Summary: Disable IPv6 makes listener work on IP address but
hostname or localhost
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: st-wong(a)cuhk.edu.hk
Target Milestone: ---
Hi,
We're compiling 2.4.49 on CentOS8.
Make test fails at "test000-rootdse" with error Can't contact LDAP server.
Debug log shows error "Address already in use".
We're quite sure the port (9011) is not in use.
Starting slapd with test command verified the error:
../servers/slapd/slapd -f testrun/slapd.1.conf -h ldap://localhost:9011
Found that it's okay to start slapd if listener URL is using IP address
instead.
Checked ldap_url_parse* call may not work as expected with V6 disabled
(configure option --disable-ipv6).
Re-do configuration and make without "--disable-ipv6" works as expected.
Would you help? Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 9 months
[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9192
Bug ID: 9192
Summary: slapo-rwm: assert triggered with invalid UUID filter
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
slapo-rwm triggers an assert when a filter with an invalid UUID syntax is used.
For example:
/opt/symas/bin/ldapsearch -x -H ldaps://ldap0.example.com -D
"cn=admin,dc=example,dc=com" -W -b dc=example,dc=com
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter:
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
# requesting: ALL
#
The above search will trigger an assert. Note that idmUUID is a custom
attribute defined as:
# idmUUID
attributetype ( 1.3.6.1.4.1.29179.2.3.3
NAME 'idmUUID'
DESC 'RFC4122 Univeral Unique Identifier for idM'
EQUALITY uuidMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
which is using the RFC4530 definition for UUID.
On the slapd side, we see:
#4 0x0000000000468650 in UUIDNormalize (usage=<optimized out>,
syntax=<optimized out>, mr=<optimized out>, val=0x7f1c58003110,
normalized=0x7f1c677fc5c0, ctx=<optimized out>)
at /home/build/sold/openldap/servers/slapd/schema_init.c:3019
No locals.
#5 0x00007f447599c55d in map_attr_value (dc=dc@entry=0x7f1c677fc730,
adp=adp@entry=0x7f1c677fc658, mapped_attr=mapped_attr@entry=0x7f1c677fc660,
value=0x7f1c58003110,
mapped_value=mapped_value@entry=0x7f1c677fc670, memctx=0x7f1c58002810,
remap=0) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:471
vtmp = {bv_len = 0, bv_val = 0x0}
freeval = 0
ad = 0x1947630
mapping = 0x0
#6 0x00007f447599ccc6 in rwm_int_filter_map_rewrite
(op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=0x7f1c58003170,
fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:559
i = <optimized out>
p = <optimized out>
ad = 0x1947630
atmp = {bv_len = 7, bv_val = 0x1900bb0 "idmUUID"}
vtmp = {bv_len = 139759712219536, bv_val = 0x7f1c58003240 "c"}
tmp = <optimized out>
ber_bvfalse = {bv_len = 18, bv_val = 0x7f447599f816
"(!(objectClass=*))"}
ber_bvtf_false = {bv_len = 3, bv_val = 0x7f447599f829 "(|)"}
ber_bvtrue = {bv_len = 15, bv_val = 0x7f447599f802 "(objectClass=*)"}
ber_bvtf_true = {bv_len = 3, bv_val = 0x7f447599f812 "(&)"}
ber_bverror = {bv_len = 9, bv_val = 0x7f447599f7f8 "(?=error)"}
ber_bvunknown = {bv_len = 11, bv_val = 0x7f447599f7ec "(?=unknown)"}
ber_bvnone = {bv_len = 8, bv_val = 0x7f447599f82d "(?=none)"}
len = <optimized out>
__PRETTY_FUNCTION__ = "rwm_int_filter_map_rewrite"
#7 0x00007f447599d7a8 in rwm_filter_map_rewrite (op=op@entry=0x7f1c580028f0,
dc=dc@entry=0x7f1c677fc730, f=<optimized out>, fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:824
rc = <optimized out>
fdc = <optimized out>
ftmp = {bv_len = 26355712, bv_val = 0x7f4475224500 "\002"}
#8 0x00007f4475999c5b in rwm_op_search (op=0x7f1c580028f0, rs=0x7f1c677fda60)
at /home/build/sold/openldap/servers/slapd/overlays/rwm.c:976
on = 0x1922620
rwmap = 0x1922800
rc = 0
dc = {rwmap = 0x1922800, conn = 0x7f4475224500, ctx = 0x7f447599f090
"searchFilterAttrDN", rs = 0x7f1c677fda60}
fstr = {bv_len = 0, bv_val = 0x0}
f = 0x0
an = 0x0
text = 0x0
roc = 0x7f1c58003218
#9 0x000000000049776a in overlay_op_walk (op=op@entry=0x7f1c580028f0,
rs=rs@entry=0x7f1c677fda60, which=which@entry=op_search, oi=oi@entry=0x1924430,
on=0x1922620)
at /home/build/sold/openldap/servers/slapd/backover.c:671
func = 0x1922678
rc = 32768
#10 0x00000000004978be in over_op_func (op=0x7f1c580028f0, rs=0x7f1c677fda60,
which=op_search) at /home/build/sold/openldap/servers/slapd/backover.c:747
oi = 0x1924430
on = <optimized out>
be = 0x728420 <slap_frontendDB>
db = {bd_info = 0x1922620, bd_self = 0x728420 <slap_frontendDB>,
be_ctrls = "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times>,
be_flags = 768, be_restrictops = 0, be_requires = 0,
be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl =
0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0,
sss_update_sasl = 0, sss_simple_bind = 0},
be_suffix = 0x18cb690, be_nsuffix = 0x18cb6e0, be_schemadn = {bv_len
= 12, bv_val = 0x1955c20 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val =
0x1955370 "cn=subschema"}, be_rootdn = {
bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0},
be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit =
{lms_t_soft = 3600, lms_t_hard = 0,
lms_s_soft = 50, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr =
0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1925890,
be_dfltaccess = ACL_READ, be_extra_anlist = 0x0,
be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0,
be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0,
__elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size =
'\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0,
be_cf_ocs = 0x7200e8 <cf_ocs+392>, be_private = 0x0,
be_next = {stqe_next = 0x18cbcc0}}
sc = <optimized out>
cb = 0x7f1c580031e8
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#11 0x0000000000431006 in do_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at
/home/build/sold/openldap/servers/slapd/search.c:247
base = {bv_len = 14, bv_val = 0x7f1c580025c7 "dc=example,dc=com"}
siz = 0
off = 0
i = <optimized out>
#12 0x000000000042ede5 in connection_operation (ctx=ctx@entry=0x7f1c677fdbd0,
arg_v=arg_v@entry=0x7f1c580028f0) at
/home/build/sold/openldap/servers/slapd/connection.c:1167
rc = 80
cancel = <optimized out>
op = 0x7f1c580028f0
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0,
sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un =
{sru_search = {r_entry = 0x0, r_attr_flags = 0,
r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref
= 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f4475224500
memctx = 0x7f1c58002810
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#13 0x000000000042f0ea in connection_read_thread (ctx=0x7f1c677fdbd0,
argv=0x16) at /home/build/sold/openldap/servers/slapd/connection.c:1314
rc = <optimized out>
cri = {op = 0x7f1c580028f0, func = 0x0, arg = 0x0, ctx = <optimized
out>, nullop = <optimized out>}
s = <optimized out>
#14 0x00007f447a585353 in ldap_int_thread_pool_wrapper (xpool=0x18b1340) at
/home/build/sold/openldap/libraries/libldap_r/tpool.c:963
pq = 0x18b1340
pool = 0x18b1250
task = 0x7f1c68000da0
work_list = <optimized out>
ctx = {ltu_pq = 0x18b1340, ltu_id = 139759972247296, ltu_key =
{{ltk_key = 0x42cbf0 <conn_counter_init>, ltk_data = 0x7f1c58002700, ltk_free =
0x42ccb0 <conn_counter_destroy>}, {
ltk_key = 0x47fef0 <slap_sl_mem_init>, ltk_data = 0x7f1c58002810,
ltk_free = 0x47fdb0 <slap_sl_mem_destroy>}, {ltk_key = 0x1ae4a40, ltk_data =
0x7f1c58102f30,
ltk_free = 0x7f44763ff550 <mdb_reader_free>}, {ltk_key = 0x4416f0
<slap_op_free>, ltk_data = 0x0, ltk_free = 0x441650 <slap_op_q_destroy>},
{ltk_key = 0x0, ltk_data = 0x7f1c58000a80,
ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}
<repeats 27 times>}}
kctx = <optimized out>
keyslot = <optimized out>
hash = <optimized out>
pool_lock = 0
freeme = 0
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#15 0x00007f4478d42ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#16 0x00007f4478a6b8cd in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 9 months
[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9197
Bug ID: 9197
Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout
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: ---
From a customer:
In order to communicate via the LB managed writable ldap, we have to ensure
that an idle connection is periodically refreshed. If we do not, the LB will
silently drop the connection after 5 minutes.
Therefore to combat that I set an olcIdleTimeout on the writable server so that
the chain cached connections will be removed before the LB timeout hits.
However the slapo-ldap client goes into CLOSE_WAIT state, which causes
subsequent ldapmodify updates being brokered by the read only instance to fail
with err=80. There appear to be a few bugs filed on this in the past against
slapd-ldap, but it's not clear if we may be hitting the same issue, or if this
is a new one.
I've also connected the read only instances directly to the writable ldap
instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT
issue is caused by the LB
These were the other threads I found as I started looking for this problem,
these are using the ldap-proxy though I think:
https://www.openldap.org/lists/openldap-technical/201301/msg00323.html
http://www.openldap.org/lists/openldap-software/201004/msg00060.html
https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html
The LB we have seems to be set to forget connections that last over 5 min per
the setting, so the 240:10:30 seemed like it should have worked and I just
thought it wasn't working because in the man page the text "Only some systems
support the customization of these values" is present. however after setting
keepalive to 60:10:30 did I maintain a stable connection, so there may be other
network settings at play I'm not aware of.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 9 months