Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by quanah＠zimbra.com
--On April 29, 2014 at 2:42:19 PM +0000 konrad.windszus(a)netcentric.biz
wrote:
>
> --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23
You waste yours and everyone else's time using the RHEL/CentOS build of
OpenLDAP. Get a real build from Symas or the LTB project.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 5 months
Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by konrad.windszus＠netcentric.biz
--Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I got a similar crash when issuing a Bind request.=20
GDB has the following information about that:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f0898ff9700 (LWP 17201)]
0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, =
env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621
1621 rc =3D TXN_BEGIN( env, NULL, txn, =
DB_READ_COMMITTED );
The stack trace exposes the following:
(gdb) bt full
#0 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, =
env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621
i =3D <value optimized out>
rc =3D <value optimized out>
data =3D <value optimized out>
ctx =3D 0x7f0898ff8b70
#1 0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, =
ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) =
at id2entry.c:343
bdb =3D 0x7f08d14cf5a0
boi =3D 0x0
txn =3D 0x0
e =3D 0x0
ei =3D <value optimized out>
rc =3D <value optimized out>
at_name =3D 0x7f08d0abdacd "(null)"
lock =3D {off =3D 8, ndx =3D 4294967295, gen =3D 32520, mode =3D =
DB_LOCK_WWRITE}
#2 0x00007f08d09ef799 in overlay_entry_get_ov (op=3D0x7f0860000970, =
dn=3D0x7f08600009a8, oc=3D0x0, ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, =
on=3D0x0) at ../../../servers/slapd/backover.c:364
oi =3D 0x7f08d14bd9d0
be =3D 0x7f08d14cf410
db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D =
"\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\=
000\000\000\000\000ihdof", be_flags =3D 551504935474,=20
be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D =
{sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 2566881772, sss_sasl =3D =
32520, sss_update_ssf =3D 0, sss_update_transport =3D 0,=20
sss_update_tls =3D 3081553768, sss_update_sasl =3D 32520, =
sss_simple_bind =3D 3513539536}, be_suffix =3D 0x7f08b7acc768, =
be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn =3D {bv_len =3D 122,=20
bv_val =3D 0x7f08b7ace810 "z"}, be_schemandn =3D {bv_len =3D =
139675828497508, bv_val =3D 0x7f086010f0b0 "."}, be_rootdn =3D {bv_len =3D=
139675850001328, bv_val =3D 0x7f08d13bf590 ""}, be_rootndn =3D {
bv_len =3D 139675417895224, bv_val =3D 0x7f08cc629670 ""}, =
be_rootpw =3D {bv_len =3D 7786477098, bv_val =3D 0x28 <Address 0x28 out =
of bounds>}, be_max_deref_depth =3D 2566882064, be_def_limit =3D {
lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft =
=3D 32520, lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, =
lms_s_pr =3D -1728085380, lms_s_pr_hide =3D 32520,=20
lms_s_pr_total =3D -1213537992}, be_limits =3D =
0x7f0898ff8310, be_acl =3D 0x7f08d0243101, be_dfltaccess =3D =
-1728085408, be_update_ndn =3D {bv_len =3D 139672336465920,=20
bv_val =3D 0x7f08d16c4bb0 "\220Ol\321\b\177"}, =
be_update_refs =3D 0x7f08d16c5bd0, be_pending_csn_list =3D =
0x7f0898ff8310, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D =
0, __owner =3D -791385128,=20
__nusers =3D 32520, __kind =3D -802934423, __spins =3D =
32520, __list =3D {__prev =3D 0x0, __next =3D 0x0}},=20
__size =3D =
"\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"=
, '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, be_pb =
=3D 0x7f08d16c4bb0,=20
be_cf_ocs =3D 0x7f0898ff8310, be_private =3D 0x7f08d14c5730, =
be_next =3D {stqe_next =3D 0x7f08d0dc87a0}}
bi =3D 0x7f08d14bd9d0
rc =3D 32768
#3 0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized out>, =
dn=3D<value optimized out>, oc=3D<value optimized out>, ad=3D<value =
optimized out>, rw=3D<value optimized out>, e=3D<value optimized out>)
at ../../../servers/slapd/backover.c:396
oi =3D <value optimized out>
on =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "over_entry_get_rw"
#4 0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../../servers/slapd/overlays/ppolicy.c:919
ppb =3D 0x7f0860001630
on =3D 0x7f08d14c7540
mod =3D 0x0
m =3D <value optimized out>
pwExpired =3D 0
ngut =3D -1
warn =3D -1
age =3D <value optimized out>
rc =3D <value optimized out>
a =3D <value optimized out>
now =3D <value optimized out>
pwtime =3D -1
nowstr =3D =
"\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b=
\177"
timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D =
0x7f0898ff8486 ""}
bi =3D 0x7f08d14d03e0
e =3D <value optimized out>
#5 0x00007f08d0993f5e in slap_response_play (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:402
sc_next =3D 0x7f08600014c8
---Type <return> to continue, or q <return> to quit---
sc_nextp =3D 0x7f0860001610
rc =3D 32768
sc =3D 0x7f0860001610
scp =3D 0x7f0898ff85e8
#6 0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476
berbuf =3D {
buffer =3D =
"\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00=
0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\=
000 =
\034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\=
000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00=
0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000=
\000\340\003M\321\b\177\000\000 =
d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00=
0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\=
000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' =
<repeats 12 times>, "p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 =
\375\324\320\b\177\000\000 =
\211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000=
\000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D=
111669149703, falign =3D 9.80908925e-45, dalign =3D =
5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 =
out of bounds>}
ber =3D 0x7f0898ff8630
rc =3D 0
bytes =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "send_ldap_response"
#7 0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750
tmp =3D 0x0
otext =3D 0x0
oref =3D 0x0
__PRETTY_FUNCTION__ =3D "slap_send_ldap_result"
#8 0x00007f08d09a1ba9 in fe_op_bind_success (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:440
No locals.
#9 0x00007f08d09a233f in fe_op_bind (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:386
bd =3D 0x7f08d0d505e0
#10 0x00007f08d09a2b19 in do_bind (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:205
ber =3D 0x7f0860000d60
version =3D 3
method =3D 128
mech =3D {bv_len =3D 0, bv_val =3D 0x0}
dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca =
"uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"}
tag =3D <value optimized out>
be =3D <value optimized out>
#11 0x00007f08d09839f9 in connection_operation (ctx=3D0x7f0898ff8b70, =
arg_v=3D0x7f0860000970) at ../../../servers/slapd/connection.c:1109
rc =3D 80
cancel =3D <value optimized out>
op =3D 0x7f0860000970
rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, =
sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, =
sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, =
r_attr_flags =3D 0,=20
r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D=
0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D =
{r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}
tag =3D 96
opidx =3D SLAP_OP_BIND
conn =3D 0x7f08d14e3350
memctx =3D 0x7f0860000ed0
memctx_null =3D 0x0
memsiz =3D 1048576
__PRETTY_FUNCTION__ =3D "connection_operation"
#12 0x00007f08d098434d in connection_read_thread (ctx=3D0x7f0898ff8b70, =
argv=3D<value optimized out>) at =
../../../servers/slapd/connection.c:1245
rc =3D <value optimized out>
cri =3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D =
0x7f0898ff8b70, nullop =3D <value optimized out>}
s =3D <value optimized out>
#13 0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper =
(xpool=3D0x7f08d13ee170) at ../../../libraries/libldap_r/tpool.c:685
pool =3D 0x7f08d13ee170
task =3D 0x7f089c000f00
work_list =3D <value optimized out>
ctx =3D {ltu_id =3D 139674903353088, ltu_key =3D {{ltk_key =3D =
0x7f08d0982540, ltk_data =3D 0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 =
<conn_counter_destroy>}, {ltk_key =3D 0x7f08d09dc7d0,=20
---Type <return> to continue, or q <return> to quit---
ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 =
<slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D =
0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, {
ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D =
0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, =
ltk_data =3D 0x7f086010ead0,=20
ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D=
0x0, ltk_data =3D 0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, =
ltk_data =3D 0x0, ltk_free =3D 0} <repeats 26 times>}}
kctx =3D <value optimized out>
keyslot =3D <value optimized out>
hash =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"
#14 0x00007f08ce8ff9d1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#15 0x00007f08ce441b6d in clone () from /lib64/libc.so.6
No symbol table info available.
I am using the binary=20
@(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $
=
mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/=
openldap-2.4.23/build-servers/servers/slapd
That should have the patch from Jan included, so I am wondering whether =
the original issue is still not solved or whether this is a separate =
issue.
Thanks,
Konrad
--Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I got =
a similar crash when issuing a Bind request. <div>GDB has the =
following information about that:</div><div><br></div><div><div =
style=3D"margin: 0px; font-size: 11px; font-family: Menlo;"><div =
style=3D"margin: 0px;"><div style=3D"margin: 0px;">Program received =
signal SIGSEGV, Segmentation fault.</div><div style=3D"margin: =
0px;">[Switching to Thread 0x7f0898ff9700 (LWP 17201)]</div><div =
style=3D"margin: 0px;">0x00007f08d0a409f8 in hdb_reader_get =
(op=3D<value optimized out>, env=3D0x7f08d14c55a0, =
txn=3D0x7f0898ff80a8) at cache.c:1621</div><div style=3D"margin: =
0px;">1621<span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>rc =3D TXN_BEGIN( env, NULL, txn, =
DB_READ_COMMITTED );</div></div><div style=3D"margin: =
0px;"><br></div><div style=3D"margin: 0px;">The stack trace exposes the =
following:</div><div style=3D"margin: 0px;"><div style=3D"margin: =
0px;">(gdb) bt full</div><div style=3D"margin: 0px;">#0 =
0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, =
env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621</div><div =
style=3D"margin: 0px;"> i =3D <value =
optimized out></div><div style=3D"margin: 0px;"> =
rc =3D <value optimized out></div><div style=3D"margin: =
0px;"> data =3D <value optimized =
out></div><div style=3D"margin: 0px;"> ctx =
=3D 0x7f0898ff8b70</div><div style=3D"margin: 0px;">#1 =
0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, =
ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) =
at id2entry.c:343</div><div style=3D"margin: 0px;"> =
bdb =3D 0x7f08d14cf5a0</div><div style=3D"margin: 0px;"> =
boi =3D 0x0</div><div style=3D"margin: 0px;"> =
txn =3D 0x0</div><div style=3D"margin: 0px;"> =
e =3D 0x0</div><div style=3D"margin: 0px;"> =
ei =3D <value optimized out></div><div =
style=3D"margin: 0px;"> rc =3D <value =
optimized out></div><div style=3D"margin: 0px;"> =
at_name =3D 0x7f08d0abdacd "(null)"</div><div style=3D"margin: =
0px;"> lock =3D {off =3D 8, ndx =3D =
4294967295, gen =3D 32520, mode =3D DB_LOCK_WWRITE}</div><div =
style=3D"margin: 0px;">#2 0x00007f08d09ef799 in =
overlay_entry_get_ov (op=3D0x7f0860000970, dn=3D0x7f08600009a8, oc=3D0x0, =
ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, on=3D0x0) at =
../../../servers/slapd/backover.c:364</div><div style=3D"margin: =
0px;"> oi =3D 0x7f08d14bd9d0</div><div =
style=3D"margin: 0px;"> be =3D =
0x7f08d14cf410</div><div style=3D"margin: 0px;"> =
db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D =
"\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\=
000\000\000\000\000ihdof", be_flags =3D 551504935474, </div><div =
style=3D"margin: 0px;"> be_restrictops =
=3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D=
0, sss_tls =3D 2566881772, sss_sasl =3D 32520, sss_update_ssf =3D 0, =
sss_update_transport =3D 0, </div><div style=3D"margin: =
0px;"> sss_update_tls =3D =
3081553768, sss_update_sasl =3D 32520, sss_simple_bind =3D 3513539536}, =
be_suffix =3D 0x7f08b7acc768, be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn =
=3D {bv_len =3D 122, </div><div style=3D"margin: 0px;"> =
bv_val =3D 0x7f08b7ace810 "z"}, =
be_schemandn =3D {bv_len =3D 139675828497508, bv_val =3D 0x7f086010f0b0 =
"."}, be_rootdn =3D {bv_len =3D 139675850001328, bv_val =3D =
0x7f08d13bf590 ""}, be_rootndn =3D {</div><div style=3D"margin: =
0px;"> bv_len =3D =
139675417895224, bv_val =3D 0x7f08cc629670 ""}, be_rootpw =3D {bv_len =3D =
7786477098, bv_val =3D 0x28 <Address 0x28 out of bounds>}, =
be_max_deref_depth =3D 2566882064, be_def_limit =3D {</div><div =
style=3D"margin: 0px;"> =
lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft =3D 32520, =
lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, lms_s_pr =3D =
-1728085380, lms_s_pr_hide =3D 32520, </div><div style=3D"margin: =
0px;"> lms_s_pr_total =3D =
-1213537992}, be_limits =3D 0x7f0898ff8310, be_acl =3D 0x7f08d0243101, =
be_dfltaccess =3D -1728085408, be_update_ndn =3D {bv_len =3D =
139672336465920, </div><div style=3D"margin: 0px;"> =
bv_val =3D 0x7f08d16c4bb0 =
"\220Ol\321\b\177"}, be_update_refs =3D 0x7f08d16c5bd0, =
be_pending_csn_list =3D 0x7f0898ff8310, be_pcl_mutex =3D {__data =3D =
{__lock =3D 0, __count =3D 0, __owner =3D -791385128, </div><div =
style=3D"margin: 0px;"> =
__nusers =3D 32520, __kind =3D -802934423, __spins =3D 32520, __list =3D =
{__prev =3D 0x0, __next =3D 0x0}}, </div><div style=3D"margin: =
0px;"> __size =3D =
"\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"=
, '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, =
be_pb =3D 0x7f08d16c4bb0, </div><div style=3D"margin: 0px;"> =
be_cf_ocs =3D 0x7f0898ff8310, be_private =3D =
0x7f08d14c5730, be_next =3D {stqe_next =3D 0x7f08d0dc87a0}}</div><div =
style=3D"margin: 0px;"> bi =3D =
0x7f08d14bd9d0</div><div style=3D"margin: 0px;"> =
rc =3D 32768</div><div style=3D"margin: 0px;">#3 =
0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized =
out>, dn=3D<value optimized out>, oc=3D<value optimized =
out>, ad=3D<value optimized out>, rw=3D<value optimized =
out>, e=3D<value optimized out>)</div><div style=3D"margin: =
0px;"> at ../../../servers/slapd/backover.c:396</div><div =
style=3D"margin: 0px;"> oi =3D <value =
optimized out></div><div style=3D"margin: 0px;"> =
on =3D <value optimized out></div><div style=3D"margin: =
0px;"> __PRETTY_FUNCTION__ =3D =
"over_entry_get_rw"</div><div style=3D"margin: 0px;">#4 =
0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at =
../../../../servers/slapd/overlays/ppolicy.c:919</div><div =
style=3D"margin: 0px;"> ppb =3D =
0x7f0860001630</div><div style=3D"margin: 0px;"> =
on =3D 0x7f08d14c7540</div><div style=3D"margin: 0px;"> =
mod =3D 0x0</div><div style=3D"margin: 0px;"> =
m =3D <value optimized out></div><div =
style=3D"margin: 0px;"> pwExpired =3D =
0</div><div style=3D"margin: 0px;"> ngut =3D =
-1</div><div style=3D"margin: 0px;"> warn =3D =
-1</div><div style=3D"margin: 0px;"> age =3D =
<value optimized out></div><div style=3D"margin: 0px;"> =
rc =3D <value optimized out></div><div =
style=3D"margin: 0px;"> a =3D <value =
optimized out></div><div style=3D"margin: 0px;"> =
now =3D <value optimized out></div><div style=3D"margin: =
0px;"> pwtime =3D -1</div><div style=3D"margin:=
0px;"> nowstr =3D =
"\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b=
\177"</div><div style=3D"margin: 0px;"> =
timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D 0x7f0898ff8486 =
""}</div><div style=3D"margin: 0px;"> bi =3D =
0x7f08d14d03e0</div><div style=3D"margin: 0px;"> =
e =3D <value optimized out></div><div style=3D"margin: =
0px;">#5 0x00007f08d0993f5e in slap_response_play =
(op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at =
../../../servers/slapd/result.c:402</div><div style=3D"margin: =
0px;"> sc_next =3D 0x7f08600014c8</div><div =
style=3D"margin: 0px;">---Type <return> to continue, or q =
<return> to quit---</div><div style=3D"margin: 0px;"> =
sc_nextp =3D 0x7f0860001610</div><div style=3D"margin: =
0px;"> rc =3D 32768</div><div style=3D"margin: =
0px;"> sc =3D 0x7f0860001610</div><div =
style=3D"margin: 0px;"> scp =3D =
0x7f0898ff85e8</div><div style=3D"margin: 0px;">#6 =
0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476</div><div =
style=3D"margin: 0px;"> berbuf =3D =
{</div><div style=3D"margin: 0px;"> =
buffer =3D =
"\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00=
0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\=
000 =
\034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\=
000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00=
0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000=
\000\340\003M\321\b\177\000\000 =
d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00=
0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\=
000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' =
<repeats 12 times>, =
"p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 =
\375\324\320\b\177\000\000 =
\211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000=
\000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D=
111669149703, falign =3D 9.80908925e-45, dalign =3D =
5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 =
out of bounds>}</div><div style=3D"margin: 0px;"> =
ber =3D 0x7f0898ff8630</div><div style=3D"margin: 0px;"> =
rc =3D 0</div><div style=3D"margin: 0px;"> =
bytes =3D <value optimized out></div><div =
style=3D"margin: 0px;"> __PRETTY_FUNCTION__ =3D=
"send_ldap_response"</div><div style=3D"margin: 0px;">#7 =
0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, =
rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750</div><div =
style=3D"margin: 0px;"> tmp =3D 0x0</div><div =
style=3D"margin: 0px;"> otext =3D =
0x0</div><div style=3D"margin: 0px;"> oref =3D =
0x0</div><div style=3D"margin: 0px;"> =
__PRETTY_FUNCTION__ =3D "slap_send_ldap_result"</div><div style=3D"margin:=
0px;">#8 0x00007f08d09a1ba9 in fe_op_bind_success =
(op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at =
../../../servers/slapd/bind.c:440</div><div style=3D"margin: 0px;">No =
locals.</div><div style=3D"margin: 0px;">#9 0x00007f08d09a233f in =
fe_op_bind (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at =
../../../servers/slapd/bind.c:386</div><div style=3D"margin: =
0px;"> bd =3D 0x7f08d0d505e0</div><div =
style=3D"margin: 0px;">#10 0x00007f08d09a2b19 in do_bind =
(op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at =
../../../servers/slapd/bind.c:205</div><div style=3D"margin: =
0px;"> ber =3D 0x7f0860000d60</div><div =
style=3D"margin: 0px;"> version =3D =
3</div><div style=3D"margin: 0px;"> method =3D =
128</div><div style=3D"margin: 0px;"> mech =3D =
{bv_len =3D 0, bv_val =3D 0x0}</div><div style=3D"margin: 0px;"> =
dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca =
"uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"}<=
/div><div style=3D"margin: 0px;"> tag =3D =
<value optimized out></div><div style=3D"margin: 0px;"> =
be =3D <value optimized out></div><div =
style=3D"margin: 0px;">#11 0x00007f08d09839f9 in connection_operation =
(ctx=3D0x7f0898ff8b70, arg_v=3D0x7f0860000970) at =
../../../servers/slapd/connection.c:1109</div><div style=3D"margin: =
0px;"> rc =3D 80</div><div style=3D"margin: =
0px;"> cancel =3D <value optimized =
out></div><div style=3D"margin: 0px;"> op =
=3D 0x7f0860000970</div><div style=3D"margin: 0px;"> =
rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, =
sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, =
sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, =
r_attr_flags =3D 0, </div><div style=3D"margin: 0px;"> =
r_operational_attrs =3D 0x0, r_attrs =
=3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D =
0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =
=3D 0}</div><div style=3D"margin: 0px;"> tag =
=3D 96</div><div style=3D"margin: 0px;"> =
opidx =3D SLAP_OP_BIND</div><div style=3D"margin: 0px;"> =
conn =3D 0x7f08d14e3350</div><div style=3D"margin: =
0px;"> memctx =3D 0x7f0860000ed0</div><div =
style=3D"margin: 0px;"> memctx_null =3D =
0x0</div><div style=3D"margin: 0px;"> memsiz =
=3D 1048576</div><div style=3D"margin: 0px;"> =
__PRETTY_FUNCTION__ =3D "connection_operation"</div><div style=3D"margin: =
0px;">#12 0x00007f08d098434d in connection_read_thread =
(ctx=3D0x7f0898ff8b70, argv=3D<value optimized out>) at =
../../../servers/slapd/connection.c:1245</div><div style=3D"margin: =
0px;"> rc =3D <value optimized =
out></div><div style=3D"margin: 0px;"> cri =
=3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D =
0x7f0898ff8b70, nullop =3D <value optimized out>}</div><div =
style=3D"margin: 0px;"> s =3D <value =
optimized out></div><div style=3D"margin: 0px;">#13 =
0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper =
(xpool=3D0x7f08d13ee170) at =
../../../libraries/libldap_r/tpool.c:685</div><div style=3D"margin: =
0px;"> pool =3D 0x7f08d13ee170</div><div =
style=3D"margin: 0px;"> task =3D =
0x7f089c000f00</div><div style=3D"margin: 0px;"> =
work_list =3D <value optimized out></div><div =
style=3D"margin: 0px;"> ctx =3D {ltu_id =3D =
139674903353088, ltu_key =3D {{ltk_key =3D 0x7f08d0982540, ltk_data =3D =
0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 =
<conn_counter_destroy>}, {ltk_key =3D =
0x7f08d09dc7d0, </div><div style=3D"margin: 0px;">---Type =
<return> to continue, or q <return> to quit---</div><div =
style=3D"margin: 0px;"> =
ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 =
<slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D =
0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, =
{</div><div style=3D"margin: 0px;"> =
ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D =
0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, =
ltk_data =3D 0x7f086010ead0, </div><div style=3D"margin: =
0px;"> ltk_free =3D =
0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D =
0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, ltk_data =3D 0x0, =
ltk_free =3D 0} <repeats 26 times>}}</div><div style=3D"margin: =
0px;"> kctx =3D <value optimized =
out></div><div style=3D"margin: 0px;"> =
keyslot =3D <value optimized out></div><div style=3D"margin: =
0px;"> hash =3D <value optimized =
out></div><div style=3D"margin: 0px;"> =
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"</div><div =
style=3D"margin: 0px;">#14 0x00007f08ce8ff9d1 in start_thread () from =
/lib64/libpthread.so.0</div><div style=3D"margin: 0px;">No symbol table =
info available.</div><div style=3D"margin: 0px;">#15 0x00007f08ce441b6d =
in clone () from /lib64/libc.so.6</div><div style=3D"margin: 0px;">No =
symbol table info available.</div></div><div style=3D"margin: =
0px;"><br></div><div style=3D"margin: 0px;">I am using the =
binary </div><div style=3D"margin: 0px;"><div style=3D"margin: =
0px;">@(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) =
$</div><div style=3D"margin: 0px;"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span><a =
href=3D"mailto:mockbuild@c6b10.bsys.dev.centos.org">mockbuild(a)c6b10.bsys.d=
ev.centos.org</a>:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/bu=
ild-servers/servers/slapd</div></div></div></div><div><br></div><div>That =
should have the patch from Jan included, so I am wondering whether the =
original issue is still not solved or whether this is a separate =
issue.</div><div>Thanks,</div><div>Konrad</div><div><br></div></body></htm=
l>=
--Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6--
9 years, 5 months
(ITS#7845) slapd debug in the background
by wingcheungma＠gmail.com
Full_Name: Wing Cheung Ma
Version: 2.4.23
OS: Rhel5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (54.240.196.185)
Hello,
I have been running slapd with -d 1 and the logfile directive in my slapd.conf
file. The issue is that I also want slapd to fork into the background once the
process starts. The bash script that starts up this process needs to exit before
the deployment is considered a success.
Is there a way to get debugging information in my logs without using syslog and
without having slapd running the foreground?
Thanks
-Wing
9 years, 5 months
(ITS#7843) ldap_set_option on LDAP not working
by korylprince＠gmail.com
Full_Name: Kory Prince
Version: 2.4.39
OS: Linux (Arch/Ubuntu)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (71.49.164.94)
Consider the following code:
#include <stdio.h>
#include <ldap.h>
void main() {
LDAP *ld;
int status = ldap_initialize(&ld, "ldaps://server:636");
if (status == LDAP_SUCCESS) {
printf("initialize success\n");
}
status = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE,
"/etc/ssl/certs/ca-certificates.crt");
status = ldap_simple_bind_s(ld, "bindDN", "pass");
if (status == LDAP_SUCCESS) {
printf("bind success\n");
}
else {
printf("%s\n", ldap_err2string(status));
}
}
This works as expected. However changing the set_option line to
status = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE,
"/etc/ssl/certs/ca-certificates.crt");
(setting the option on the LDAP) causes the bind to fail.
Using python-ldap gives me a bit more info:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed (unable to get local issuer certificate)
I have compiled libldap 2.4.39 on Arch and Ubuntu and am getting the same
result.
Interestingly enough, the version that comes packaged on Ubuntu 12.04 (2.4.28)
works fine, but compiling that version myself gives the same error.
9 years, 5 months
(ITS#7842) mdb readers/writer exclusion protocol, as implemented, is racy.
by rsbx＠acm.org
Full_Name: Raymond S Brand
Version: mdb.master
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (107.145.137.13)
[I would have uploaded this to the ftp.openldap.org but there was no space.]
As implemented, the mdb readers/writer exclusion protocol has a race condition
that could result in a writer reclaiming and over-writing pages still in use
by a reader.
Pseudo code of the snapshot locking protocols of reader and writer
transactions. The labeled sections, for the purposes of this analysis, can be
assumed to execute atomically.
READER
======
*R1* t0 = meta[0].txid; t1 = meta[1].txid
if (t1 > t0)
t0 = t1
*R2* readers[me].txid = t0
*R3* snapshot_root = meta[t0&1].snapshot
*R4* /* lookup data */
*R5* readers[me].txid = -1 // Release snapshot
WRITER
======
*W1* lock(writer, EXCLUSIVE)
curr_txid = meta[0].txid
if (meta[1].txid > curr_txid)
curr_txid = meta[1].txid
*W2* oldest = curr_txid
for (i=0; i<reader_slots; i++)
t = readers[i].txid
if (t != -1 && t < oldest)
oldest = t
*W3* reclaim_old_pages(oldest)
/*
** Commit new transaction
*/
*W4* unlock(writer)
---------------------------------------------------------------------------
Adversarial scheduling analysis:
The following timeline demonstrates that a writer can reclaim pages in use by a
reader.
T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
R1 R2 R3 R4
W1 W2 W3 W4 * W1 W2 W3
T0 Reader has found the latest txid, Xn.
T1->T4 Reader is not scheduled to run and a write transaction commits, Xn+1.
T5 Reader is still not scheduled and another write transaction starts.
T6 Writer finds that the oldest referenced transaction is the last
committed transaction, Xn+1.
T7 Reader records Xn in the reader table.
T8 Reader gets the snapshot root page for transaction Xn.
T9 Writer, believing that Xn+1 is the oldest reference transaction,
reclaims the pages of transaction Xn.
T10 Reader attempts to navigate pages of a transaction, Xn, that has been
reclaimed and "Bad Things Happen".
In fact, bad things will happen if an even number of write transactions commit
between W4 and W1, represented by the '*', in the timeline above.
The fix is to search for the highest txid in R1 and between R2 and R3.
Optionally, followed by recording the txid, of the snapshot root found in R3,
in the reader's reader table slot to, possibly, increase the number of
reclaimable transactions.
The lack of compiler and memory barriers in the implementation of the locking
protocol is also of concern.
Beyond the above, the code in mdb_txn_renew0() after the
"/* Copy the DB info and flags */"
comment appears to have a number of data races.
---
libraries/liblmdb/mdb.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
index e0f551e..908417c 100644
--- a/libraries/liblmdb/mdb.c
+++ b/libraries/liblmdb/mdb.c
@@ -533,11 +533,11 @@ typedef struct MDB_rxbody {
* started from so we can avoid overwriting any data used in that
* particular version.
*/
- txnid_t mrb_txnid;
+ volatile txnid_t mrb_txnid;
/** The process ID of the process owning this reader txn. */
- MDB_PID_T mrb_pid;
+ volatile MDB_PID_T mrb_pid;
/** The thread ID of the thread owning this txn. */
- pthread_t mrb_tid;
+ volatile pthread_t mrb_tid;
} MDB_rxbody;
/** The actual reader record, with cacheline padding. */
@@ -585,12 +585,12 @@ typedef struct MDB_txbody {
* This is recorded here only for convenience; the value
can always
* be determined by reading the main database meta pages.
*/
- txnid_t mtb_txnid;
+ volatile txnid_t mtb_txnid;
/** The number of slots that have been used in the reader
table.
* This always records the maximum count, it is not
decremented
* when readers release their slots.
*/
- unsigned mtb_numreaders;
+ volatile unsigned mtb_numreaders;
} MDB_txbody;
/** The actual reader table definition. */
@@ -854,7 +854,7 @@ typedef struct MDB_meta {
/** Any persistent environment flags. @ref mdb_env */
#define mm_flags mm_dbs[0].md_flags
pgno_t mm_last_pg; /**< last used page in
file */
- txnid_t mm_txnid; /**< txnid that
committed this page */
+ volatile txnid_t mm_txnid; /**< txnid that committed this
page */
} MDB_meta;
/** Buffer for a stack-allocated meta page.
@@ -2303,10 +2303,12 @@ mdb_txn_renew0(MDB_txn *txn)
if (txn->mt_flags & MDB_TXN_RDONLY) {
if (!ti) {
+ /* No readers table; app responsible for locking */
meta = env->me_metas[ mdb_env_pick_meta(env) ];
txn->mt_txnid = meta->mm_txnid;
txn->mt_u.reader = NULL;
} else {
+ /* Has readers table */
MDB_reader *r = (env->me_flags & MDB_NOTLS) ?
txn->mt_u.reader :
pthread_getspecific(env->me_txkey);
if (r) {
@@ -2347,8 +2349,12 @@ mdb_txn_renew0(MDB_txn *txn)
return rc;
}
}
- txn->mt_txnid = r->mr_txnid = ti->mti_txnid;
txn->mt_u.reader = r;
+ r->mr_txnid = ti->mti_txnid;
+
+ /* Really need a memory barrier here */
+
+ txn->mt_txnid = r->mr_txnid = ti->mti_txnid;
meta = env->me_metas[txn->mt_txnid & 1];
}
} else {
@@ -2376,10 +2382,10 @@ mdb_txn_renew0(MDB_txn *txn)
}
/* Copy the DB info and flags */
- memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db));
+ memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); /* Racy */
/* Moved to here to avoid a data race in read TXNs */
- txn->mt_next_pgno = meta->mm_last_pg+1;
+ txn->mt_next_pgno = meta->mm_last_pg+1; /* Racy */
for (i=2; i<txn->mt_numdbs; i++) {
x = env->me_dbflags[i];
--
1.9.0.138.g2de3478
9 years, 5 months
Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr
hello,
FYI, I just stumbled on an old topic from 2011:
--------------------------------- 8< ---------------------------------
Re: cn=config replication to consumer / slave servers
________________________________
To: Christopher Strider Cook <ccook(a)pandora.com>
Subject: Re: cn=config replication to consumer / slave servers
From: Howard Chu <hyc(a)symas.com>
Date: Tue, 19 Apr 2011 17:27:58 -0700
Cc: Quanah Gibson-Mount <quanah(a)zimbra.com>, openldap-technical(a)openldap.org
________________________________
Christopher Strider Cook wrote:
> So, the pointer to test059 was exactly what this issue needed and
> following it has lead me to an very good working setup with one puzzling
> final step.
> The problem I now face is that the initial cn=config entries used to do
> the first sync do not get overwritten by the data from the master. So
> the install password doesn't get replaced nor do the updated retry
> timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries have
> newer timestamps than those on the master.
> How can this be overcome from the perspective of the slave server.
> Updating the entries on the master triggers the update as you would
> expect. Is there a way to put the stub entries onto the slave with a
> timestamp in the past so that they get overwritten during the first
> sync? Or is there another way to trigger them to be updated?
Use slapd -c. Read the slapd(8) manpage.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------------------------- 8< ---------------------------------
you always answer "use slapd -c" to this type of question, but you
_never_ mention that newer entries are never overwritten by older
entries. so _in this context_ this answer is useless
building the consumer before the provider is not an option, also _in
this context_
so the only option left is to update the master with an empty modify
ldif to force update of the timestamps
I personnaly use
--------------------------------- 8< ---------------------------------
dn: cn=config
changetype: modify
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
dn: olcDatabase={0}config,cn=config
changetype: modify
--------------------------------- 8< ---------------------------------
besides, if you do this update with a user from a different database,
e.g cn=admin,dc=my,dc=tld the seed replication fails because
modifiersName contains a non existing DN (at the time of the
replication). I consider this a bug also.
anyway, thanks for your dedicated time and effort. OpenLDAP is really
a great software. I have a lot to learn yet. so please bear with me
:-)
best regards,
2014-04-20 11:33 GMT+04:00 Jephte Clain <jephte.clain(a)univ-reunion.fr>:
> hello,
>
> thanks for your answer.
> see my response below
>
> 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>:
>> Jephte.Clain(a)univ-reunion.fr wrote:
>>>
>>> Full_Name: Jephte CLAIN
>>> Version: 2.4.39
>>> OS: Debian 6 64bits
>>> URL: http://jclain.fr/openldap-its/
>>> Submission from: (NULL) (93.176.62.129)
>>>
>>>
>>> I have scripts to test several replication scenarii, that setup the LDAP
>>> environment then allow me to play with parameters as I see fit.
>>>
>>> I believe that there is a bug with the "seed replication" that allow one
>>> to
>>> build an exact clone of a master with minimal configuration on the slave
>>> side.
>>
>>
>> There is no bug. The syncrepl consumer is working as designed. If you want
>> the consumer's entries to be automatically overwritten, create the consumer
>> first so that its seed entries have older timestamps than the provider.
>
> ok, it works as designed. I just didn't know what the design was :-)
> quoting man slapd:
> Use only the rid part to force a full reload.
> I guess I didn't notice that the word "full" have a different meaning
> here than usual
>
> about creating the consumer first. you are kidding, right? in
> production, the provider exists long before the consumer is set up.
> the tests I do are based on the production state.
>
> anyway, my automated scripts "touch" the provider after setting up the
> slave, so this is not a problem.
> It's just that I would prefer not to have wasted time wondering why
> the slave was not being updated even though I asked for a "full"
> reload
>
> Thanks for your answer. It's now clearer in my mind.
> I Cc the openldap-technical list, this can help others.
>
>>
>>> note: the tests below require 2 VMs, or running the two slapd instances in
>>> chroots, because a clone replica requires the data files to be in the same
>>> path...
>>
>>
>> That's far overkill. All you need to do is configure your test scripts to
>> use relative pathnames. test049 (and others) in the test suite already
>> operates this way.
>
> ok thanks for pointing this out
> It has been a while since I read the tests scripts. I should have paid
> more attention...
>
>>
>> Closing this ITS.
>>
>>> I attach two scripts to replicate the problem. they require root (they
>>> uses
>>> chroots)
>>> this is with openldap 2.4.39 on debian squeeze. some paths may have to be
>>> fixed
>>> in the scripts below
>>>
>>> use jclain-20140419-0start.sh to:
>>> - create a ldap server to be served on ldap://localhost:3890
>>> - start the master in chroot
>>> (the logs are in /jclain-slapd-test/master.data/slapd.log)
>>> - create a seed ldap replica to be served on ldap://localhost:3891 with
>>> ldap://localhost:3890 as the provider
>>> - start it in chroot with option -c rid=0
>>> (the logs are in /jclain-slapd-test/slave.data/slapd.log)
>>>
>>> use jclain-20140419-1stop.sh to:
>>> - stop the servers
>>> - umount the chroots
>>>
>>> If I understand the manual correctly, after 0start.sh, the replica should
>>> be
>>> identical to the master thanks to -c rid=0
>>> BUT, the log on the replica says:
>>>
>>> 534d5481 dn_callback : new entry is older than ours cn=config ours
>>> 20140415154713.807278Z#000000#000#000000, new
>>> 20140415154704.888204Z#000000#000#000000
>>>
>>> and indeed, the seed entries are NOT overwritten
>>> I have to "touch" them on the master to force the replication.
>>>
>>> I have uploaded the scripts to http://jclain.fr/openldap-its/
>>>
>>> thanks in advance
>>>
>>>
--
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06
9 years, 5 months
(ITS#7841) high disk utilization
by dmitrii.fonariuk＠gmail.com
Full_Name: Dmitrii Fonariuk
Version: 2.4.38
OS: rhEL6.x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (91.210.4.1)
There is a big value of DISK WRITE parameter in utility Iotop when in MDB a lot
of Free pages (Freelist Status). Supposedly this situation arises from memory
management algorithm. The algorithm FIFO is used for pages block allocation in
free pages pool. We touched and dirty different pages on every modification
transaction, which then flushed to disk by system process Flush. Perhaps it
would be better to use the LIFO, which will to dirty the same pages by different
transactions, which reduces the load on the disk?
we use MDB with EnvFlags writemap and mapasync.
9 years, 5 months
Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr
hello,
thanks for your answer.
see my response below
2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>:
> Jephte.Clain(a)univ-reunion.fr wrote:
>>
>> Full_Name: Jephte CLAIN
>> Version: 2.4.39
>> OS: Debian 6 64bits
>> URL: http://jclain.fr/openldap-its/
>> Submission from: (NULL) (93.176.62.129)
>>
>>
>> I have scripts to test several replication scenarii, that setup the LDAP
>> environment then allow me to play with parameters as I see fit.
>>
>> I believe that there is a bug with the "seed replication" that allow one
>> to
>> build an exact clone of a master with minimal configuration on the slave
>> side.
>
>
> There is no bug. The syncrepl consumer is working as designed. If you want
> the consumer's entries to be automatically overwritten, create the consumer
> first so that its seed entries have older timestamps than the provider.
ok, it works as designed. I just didn't know what the design was :-)
quoting man slapd:
Use only the rid part to force a full reload.
I guess I didn't notice that the word "full" have a different meaning
here than usual
about creating the consumer first. you are kidding, right? in
production, the provider exists long before the consumer is set up.
the tests I do are based on the production state.
anyway, my automated scripts "touch" the provider after setting up the
slave, so this is not a problem.
It's just that I would prefer not to have wasted time wondering why
the slave was not being updated even though I asked for a "full"
reload
Thanks for your answer. It's now clearer in my mind.
I Cc the openldap-technical list, this can help others.
>
>> note: the tests below require 2 VMs, or running the two slapd instances in
>> chroots, because a clone replica requires the data files to be in the same
>> path...
>
>
> That's far overkill. All you need to do is configure your test scripts to
> use relative pathnames. test049 (and others) in the test suite already
> operates this way.
ok thanks for pointing this out
It has been a while since I read the tests scripts. I should have paid
more attention...
>
> Closing this ITS.
>
>> I attach two scripts to replicate the problem. they require root (they
>> uses
>> chroots)
>> this is with openldap 2.4.39 on debian squeeze. some paths may have to be
>> fixed
>> in the scripts below
>>
>> use jclain-20140419-0start.sh to:
>> - create a ldap server to be served on ldap://localhost:3890
>> - start the master in chroot
>> (the logs are in /jclain-slapd-test/master.data/slapd.log)
>> - create a seed ldap replica to be served on ldap://localhost:3891 with
>> ldap://localhost:3890 as the provider
>> - start it in chroot with option -c rid=0
>> (the logs are in /jclain-slapd-test/slave.data/slapd.log)
>>
>> use jclain-20140419-1stop.sh to:
>> - stop the servers
>> - umount the chroots
>>
>> If I understand the manual correctly, after 0start.sh, the replica should
>> be
>> identical to the master thanks to -c rid=0
>> BUT, the log on the replica says:
>>
>> 534d5481 dn_callback : new entry is older than ours cn=config ours
>> 20140415154713.807278Z#000000#000#000000, new
>> 20140415154704.888204Z#000000#000#000000
>>
>> and indeed, the seed entries are NOT overwritten
>> I have to "touch" them on the master to force the replication.
>>
>> I have uploaded the scripts to http://jclain.fr/openldap-its/
>>
>> thanks in advance
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
cordialement,
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06
9 years, 5 months
Re: (ITS#7840) bug with initial/seed syncrepl
by hyc＠symas.com
Jephte.Clain(a)univ-reunion.fr wrote:
> Full_Name: Jephte CLAIN
> Version: 2.4.39
> OS: Debian 6 64bits
> URL: http://jclain.fr/openldap-its/
> Submission from: (NULL) (93.176.62.129)
>
>
> I have scripts to test several replication scenarii, that setup the LDAP
> environment then allow me to play with parameters as I see fit.
>
> I believe that there is a bug with the "seed replication" that allow one to
> build an exact clone of a master with minimal configuration on the slave side.
There is no bug. The syncrepl consumer is working as designed. If you want the
consumer's entries to be automatically overwritten, create the consumer first
so that its seed entries have older timestamps than the provider.
> note: the tests below require 2 VMs, or running the two slapd instances in
> chroots, because a clone replica requires the data files to be in the same
> path...
That's far overkill. All you need to do is configure your test scripts to use
relative pathnames. test049 (and others) in the test suite already operates
this way.
Closing this ITS.
> I attach two scripts to replicate the problem. they require root (they uses
> chroots)
> this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed
> in the scripts below
>
> use jclain-20140419-0start.sh to:
> - create a ldap server to be served on ldap://localhost:3890
> - start the master in chroot
> (the logs are in /jclain-slapd-test/master.data/slapd.log)
> - create a seed ldap replica to be served on ldap://localhost:3891 with
> ldap://localhost:3890 as the provider
> - start it in chroot with option -c rid=0
> (the logs are in /jclain-slapd-test/slave.data/slapd.log)
>
> use jclain-20140419-1stop.sh to:
> - stop the servers
> - umount the chroots
>
> If I understand the manual correctly, after 0start.sh, the replica should be
> identical to the master thanks to -c rid=0
> BUT, the log on the replica says:
>
> 534d5481 dn_callback : new entry is older than ours cn=config ours
> 20140415154713.807278Z#000000#000#000000, new
> 20140415154704.888204Z#000000#000#000000
>
> and indeed, the seed entries are NOT overwritten
> I have to "touch" them on the master to force the replication.
>
> I have uploaded the scripts to http://jclain.fr/openldap-its/
>
> thanks in advance
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
