openldap-bugs

openldap-bugs@openldap.org

1 participants
21410 discussions

Re: (ITS#8432) Never ending operation modifications with 3+ MMR nodes
by hyc＠symas.com 08 Jun '16

08 Jun '16

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > In MMR node, when there is > 2 nodes, operations can get sent out endlessly. > > For example, we see this modification occur at 20160603194926.427963Z You seem to have a large clock sync problem. > > Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 be_modify > cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x121c8680 > 20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x9403600 20160527111854.508810Z#000000#004#000000 How did a CSN from 20160527 get queued on 20160603? > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 > cookie=rid=102,sid=004,csn=20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: dsysyncrep2: rid=102 CSN too old, ignoring > 20160603194926.417898Z#000000#001#000000 > (reqStart=20160603194922.988081Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 > cookie=rid=101,sid=002,csn=20160603194926.417898Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 CSN too old, ignoring > 20160603194926.417898Z#000000#001#000000 > (reqStart=20160603194931.992576Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=100 > cookie=rid=100,sid=001,csn=20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x120c1c80 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_matchops: skipping original sid > 001 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x93aae80 20160527095853.061949Z#000000#004#000000 And another one. > Jun 3 14:49:22 ldap01 slapd[14014]: syncrepl_message_to_op: rid=100 be_modify > cn=edge02e.zimbra.com,cn=servers,cn=zimbra (0) > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x1104d080 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0xac25300 20160527084152.674596Z#000000#004#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 > cookie=rid=102,sid=004,nsn=20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=102 CSN too old, ignoring > 20160603194926.427963Z#000000#001#000000 > (reqStart=20160603194922.996275Z,cn=accesslog) > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=100 > cookie=rid=100,sid=001,csn=20160603194926.433237Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0x1116e600 > 20160603194926.433237Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_matchops: skipping origil l sid > 001 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: syncprov_sendresp: to=002, > cookie=rid=100,sid=003 > Jun 3 14:49:22 ldap01 slapd[14014]: do_syncrep2: rid=101 > cookie=rid=101,sid=002 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_queue_csn: queueing 0xf0cf380 > 20160603194926.427963Z#000000#001#000000 > Jun 3 14:49:22 ldap01 slapd[14014]: slap_graduate_commit_csn: removing > 0x122e2cc0 20160527095853.613262Z#000000#004#000000 And another. There are more in the rest of the output you pasted. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8433) slapd deadlocks on shutdown in 3+ MMR configuration with active writes
by hyc＠symas.com 08 Jun '16

08 Jun '16

quanah(a)openldap.org wrote: > Full backtrace of all threads: > > > Thread 4 (Thread 0x7f146ac9d700 (LWP 16805)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > No locals. > #1 0x00007f3c70fe8171 in ldap_pvt_thread_cond_wait (cond=0x1fa0038, > mutex=0x1fa0010) at thr_posix.c:277 > No locals. > #2 0x00007f3c70fe63c2 in ldap_pvt_thread_pool_destroy (tpool=0x7618c0 > <connection_pool>, run_pending=1) at tpool.c:817 > pool = 0x1f763c0 > pptr = 0x1f763c0 > pq = 0x1fa0000 > task = 0x7f3c716a61c8 > i = 0 > #3 0x0000000000438967 in slapd_daemon_task (ptr=0x1d7bce8) at daemon.c:2829 > l = 3 > last_idle_check = 1464372736 > ebadf = 0 > tid = 0 > #4 0x00007f3c70552184 in start_thread (arg=0x7f146ac9d700) at > pthread_create.c:312 > __res = <optimized out> > pd = 0x7f146ac9d700 > now = <optimized out> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725667686144, > -1093867468031317215, 0, 0, 139725667686848, 139725667686144, > 1078920827726146337, 1056426161274956577}, > mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = > {prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = <optimized out> > pagesize_m1 = <optimized out> > sp = <optimized out> > freesize = <optimized out> > __PRETTY_FUNCTION__ = "start_thread" > #5 0x00007f3c7027f37d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > No locals. Thread 4 is waiting for the other threads to finish. > > Thread 3 (Thread 0x7f1468498700 (LWP 16810)): > #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 > No locals. > #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x5d36630, buf=0x5a3c057, > len=433) at sockbuf.c:490D0D > __PRETTY_FUNCTION__ = "sb_stream_read" Thread 3 is inside OpenSSL, it thinks there are 433 bytes to read on this socket and it's waiting for them to arrive. There's not much we can do in slapd about this. > #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d36d20, buf=0x5a3c057, > len=433) at sockbuf.c:829 > ret = 79 > ebuf = "PjIh\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\250\062H\004\000\000\000\000'\000\000\000\000\000\000\000\240\361H\004\000\000\000\000P\026u\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\0006364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hxIh\t\000\000\000\300lIh\024\177\000\000\220jIh\024\177\000" > #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x5a93110, > buf=0x5a3c057 "\004\areqType1\b\004\006modify02\004\005reqDN1)\004'uid=gtillman,ou=people,dc=zimbra,dc=com0\201\317\004\006reqMod1\201\304\004:zimbraAuthTokens:- > 1988626989|1464372357970|8.7.0_RC1_1601\004\063entryCSN:= > 20160527182235.762156Z#000000#003#000000\004."..., len=433) at tls_o.c:721 > p = 0x5a6caa0 > ret = 79 > #4 0x00007f3c6f19988b in BIO_read () from > /opt/zimbra/common/lib/libcrypto.so.1.0.0 > No symbol table info available. > #5 0x00007f3c6f501ffc in ssl3_read_n () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #6 0x00007f3c6f503ebf in ssl3_read_bytes () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #7 0x00007f3c6f50033b in ssl3_read () from > /opt/zimbra/common/lib/libssl.so.1.0.0 > No symbol table info available. > #8 0x00007f3c7101f093 in tlso_sb_read (sbiod=0x5d382e0, buf=0xcb4f93f, len=8) > at tls_o.c:881 > p = 0x5a6caa0 > ret = 635655159814 > err = 28 > __PRETTY_FUNCTION__ = "tlso_sb_read" > #9 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d37800, buf=0xcb4f93f, len=8) > at sockbuf.c:829 > ret = 0 > ebuf = "\000\000\000\000\000\000\000\000\300\211Ih\024\177\000\000\000\207Ih\024\177\000\000\000\000\000\000\000\000\000\000pmIh\024\177\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\240h%h\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000\000\240mIh\000\000\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\320mIh\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000" > #10 0x00007f3c70dd2291 in ber_int_sb_read (sb=0x5d363c0, buf=0xcb4f93f, len=8) > at sockbuf.c:423 > ret = 0 > __PRETTY_FUNCTION__ = "ber_int_sb_read" > #11 0x00007f3c70dcebbf in ber_get_next (sb=0x5d363c0, len=0x7f1468496f00, > ber=0xcb4f930) at io.c:532 > sblen = 8 > buf = "\000\000\000\000\000\000" > tlen = 0 > __PRETTY_FUNCTION__ = "ber_get_next" > #12 0x00007f3c70fea22f in try_read1msg (ld=0x5d36d50, msgid=3, all=0, > lc=0x3d9b320, result=0x7f1468497190) at result.c:491 > ber = 0xcb4f930 > newmsg = 0x0 > l = 0x0 > prev = 0x0 > id = 0 > tag = 0 > len = 0 > foundit = 0 > lr = 0x0 > tmplr = 0x0 > dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = > 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, > lr_res_errno = 0, > lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, > lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext > = 0x0, lr_prev =x0x0, > lr_next = 0x0} > tmpber = {ber_opts = {lbo_valid = -12608, lbo_options = 474, lbo_debug = > 0}, ber_tag = 5341050, ber_len = 0, ber_usertag = 5014619, ber_buf = 0x0, > ber_ptr = 0x0, ber_end = 0x0, > ber_sos_ptr = 0x574963a4 <error: Cannot access memory at address > 0x574963a4>, ber_rwptr = 0x0, ber_memctx = 0x67} > rc = 0 > refer_cnt = 0 > hadref = 0 > simple_request = 0 > err = 0 > lderr = 0 > __PRETTY_FUNCTION__ = "try_read1msg"A%A#13 0x00007f3c70fe9e53 in > wait4msg (ld=0x5d36d50, msgid=3, all=0, timeout=0x7f14684971f0, > result=0x7f1468497190) at result.c:362 > lnext = 0x0 > serviced = 1 > lc_ready = 1 > rc = -2 > tv = {tv_sec = 0, tv_usec = 0} > tv0 = {tv_sec = 0, tv_usec = 0} > start_time_tv = {tv_sec = 1464427439, tv_usec = 944352} > tvp = 0x7f14684970a0 > lc = 0x3d9b320 > __PRETTY_FUNCTION__ = "wait4msg" > #14 0x00007f3c70fe9574 in ldap_result (ld=0x5d36d50, msgid=3, all=0, > timeout=0x7f14684971f0, result=0x7f1468497190) at result.c:117 > rc = 0 > __PRETTY_FUNCTION__ = "ldap_result" > #15 0x00000000004bd6b2 in do_syncrep2 (op=0x7f1468497720, si=0x1dacec0) at > syncrepl.c:841 > Thread 2 (Thread 0x7f1467c97700 (LWP 16812)): > #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 > No locals. > #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x3dac8b0, buf=0x23cc1a8, > len=96) at sockbuf.c:493 > __PRETTY_FUNCTION__ = "sb_stream_read" > #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x3dac850, buf=0x23cc1a8, len=96) > at sockbuf.c:829 > ret = 416 > ebuf = "PZ\311g\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\230\264\343\005\000\000\000\000'\000\000\000\000\000\000\000P~\344\005\000\000\000\000@C5Cru\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\000\364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hh\311g\n\000\000\000\300\\\311g\024\177\000\000\220Z\311g\024\177\000" > #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x244b2d0, > buf=0x23cc1a8 "\240F0D\004\030\061.3.6.1.4.1.4203.1.9.1.2\004(0&\n\001\001\004\020\004@\320&\270\206\020\065\223\244\347B\322ף\327\004\017rid=102,sid=001췫\272\005\324a`\346\343\373\335\062\065\223\a\363\363Sv\003\003\003\003\063.1.9.1.2\004(0&\n\001\001\004\020\003\362\377\004\270\206\020\065\223\236\347B\322ף\327\004\017rid=102,sid=001\027ל{\026g\264\262\210\331U]\330#\020u\241ʂ\206\b\b\b\b\b\b\b\b\bntryCSN:= > 20160527182329"..., len=96% a at tls_o.c:721 > p = 0x3da51e0 > ret = 416 > #4 0x00007f3c6f19988b in BIO_read () from > /opt/zimbra/common/lib/libcrypto.so.1.0.0 > No symbol table info available. Thread 2 is in the same state as thread 3. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8434) Config entry cleanup on Add should be run unconditionally
by hyc＠symas.com 08 Jun '16

08 Jun '16

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:c7f:221f:c00:a3e:8eff:fe52:dac5) > > > With cn=config the ConfigLDAPadd function might have to allocate resources that > are needed by the time the attributes/config directives are being processed > since there is no indication which directives there are and what order they come > in. When using LDAPAdd, attributes are processed in the order of their schema definitions. > If any of the config values fail validation, the configuration code has to react > and clean up - which is possible using ca->cleanup. No, that's not its purpose. If anything fails, the entire config entry must be wiped out. LDAPAdd is all-or-nothing. > While Modify handling (config_modify_internal) already calls ca->cleanup in each > case, this is not true for config_add_internal, there it is only run on success. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8438)
by zvika.ferentz＠protegrity.com 08 Jun '16

08 Jun '16

--_000_DM2PR08MB13386A193A5315910812CF2E8D5E0DM2PR08MB1338namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you . Indeed I was able to reproduce with the latest Debian package (slapd_2.4.31= +really2.4.40+dfsg-1+deb8u1~bpo70+1_amd64) . I will forward this bug to the Debian team however I feel that this has not= hing to do with Debian as the slapd shows the initial shutdown log and not= the rest. Thank you for the quick reply !! zvika --_000_DM2PR08MB13386A193A5315910812CF2E8D5E0DM2PR08MB1338namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Thank you .<o:p></o:p></p> <p class=3D"MsoNormal">Indeed I was able to reproduce with the latest Debia= n package (slapd_2.4.31+really2.4.40+dfsg-1+deb8u1~bpo70+1_= amd64) . <o:p></o:p></p> <p class=3D"MsoNormal">I will forward this bug to the Debian team however I= feel that this has nothing to do with Debian as the slapd  shows the = initial shutdown log and not the rest.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Thank you for the quick reply !!<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">zvika<o:p></o:p></p> </div> </body> </html> --_000_DM2PR08MB13386A193A5315910812CF2E8D5E0DM2PR08MB1338namp_--

1 0

Re: (ITS#8438) slapd won't stop (shutdown) on multi-core system under stress
by ryan＠openldap.org 08 Jun '16

08 Jun '16

On Wed, Jun 08, 2016 at 04:45:38PM +0000, zvika.ferentz(a)gmail.com wrote: >Version: 2.4.31 (deb7u2) >OS: Debian Wheezy This version is no longer supported (except for critical security updates via Debian-LTS). Would you please try a more recent version? openldap 2.4.40 is available in jessie and in wheezy-backports. If you can reproduce the problem with this version, please report the bug to the Debian bug tracker. openldap 2.4.44 sources are available from openldap.org, and binary packages are available from ltb-project.org. If you can reproduce the problem with this version, please follow up to this ITS.

1 0

Re: (ITS#8438) slapd won't stop (shutdown) on multi-core system under stress
by quanah＠zimbra.com 08 Jun '16

08 Jun '16

--On Wednesday, June 08, 2016 5:45 PM +0000 zvika.ferentz(a)gmail.com wrote: > Full_Name: zvika ferentz > Version: 2.4.31 (deb7u2) OpenLDAP 2.4.31 is several years old (2012/04/21). This ITS will be closed. If you can reproduce the problem using a current version of OpenLDAP, please feel free to file a new ITS. If you want support with the myriad problems in the Debian builds, file a bug with Debian. Thanks. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8438) slapd won't stop (shutdown) on multi-core system under stress
by zvika.ferentz＠gmail.com 08 Jun '16

08 Jun '16

Full_Name: zvika ferentz Version: 2.4.31 (deb7u2) OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.51.117.60) Greetings, I've noticed that sometimes the "slapd" fails to stop. I can reproduce the problem only on machines with multiple cores (more than 2) when there are many concurrent connections and the server is under a heavy "stress" . note that this is a debian wheezy x64 so probably it's not the standard vanilla slapd , however from the logs&source it doesn't look like it's related to the OS. In the logs i was able to identify the first "shutdown" log: daemon: shutdown requested and initiated However the next expected shutdown logs are missing ("waiting for ... operations/tasks to finish" and "slapd stopped") . Hence i believe that it's related to closing the sockets/listeners (this is my guess based on the source code, however i never debugged/proved it). Please note that i'm using virtual environment so i was able to reproduce it only when i used more than 4 cores. How to reproduced it: --------------------- - Open two terminals. - On terminal #1 i'm just manually running "slapd restart" commands: # /etc/init.d/slapd status ; /etc/init.d/slapd restart - On terminal #2 i'm running a infinite loops of simple "ldapsearch" (100 concurrent processes running loops of ldapsearch). Terminal #2 is trying to simulate many concurrent read operations. see "more information" later for the exact scripts that i used. Incorrect behavior: ------------------- The "slapd restart" works a few times, and then the "stop" operation fails. The stop continues to fail even if i stop all "stress" and terminate all ldapsearch/connections (CPU is 99% idle !) Expected Behavior: ------------------ All slapd stop/restart operations complete successfully More Information (optional):D%D ---------------------------- On terminal#2 i used a very simple script to generate a "read only" stress: # cat > ldaploop.sh << EOF #!/bin/sh while true ; do ldapsearch -x -Z ; done EOF # cat > manyloops.sh << "EOF" #!/bin/sh for i in `seq 1 100` ; do ( ./ldaploop.sh &) ; done EOF As previously mentioned, i ran the "manyloops.sh" to generate 100 running processes where each one simply runs "ldapsearch" (locally). thanks in advance, Zvika Ferentz

1 0

(ITS#8437) openldap-2.4.44 slapd.conf: back-sql database parameters, only first character
by piero.astolfi＠gmx.com 08 Jun '16

08 Jun '16

Full_Name: Piero Astolfi Version: openldap-2.4.44 OS: CentOS Linux release 7.1.1503 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.1.178.237) I compiled openldap-2.4.44 enabling the sql backend and configured slapd.conf accordingly, however slapd fails to start. It seems that only the first character of the database parameters are used. After changing the username and the password in my DB to a single character I can successfully connect to the DB but every sql query fails. As you can see in my /var/lib/mysql/server_audit.log the query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" results in the single character "S", the same happens to the username "ldap_user" that results in the single character "l". Do you have any suggestions on how to proceed? # cat /usr/local/etc/openldap/slapd.conf [...] database sql dbname ldap_dbname dbuser ldap_user dbpasswd ldap_password # /usr/local/libexec/slapd -d Any -f /usr/local/etc/openldap/slapd.conf [...] 57581a99 ==>backsql_get_db_conn() 57581a99 ==>backsql_open_db_handle() 57581a9%3<==backsql_open_db_handle() 57581a99 <==backsql_get_db_conn() 57581a99 ==>backsql_load_schema_map() 57581a99 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 57581a99 backsql_load_schema_map(): error executing oc_query: 57581a99 Return code: -1 57581a99 nativeErrCode=1064 SQLengineState=��� msg="" 57581a99 backsql_db_open(): schema mapping failed, exiting 57581a99 backend_startup_one (type=sql, suffix="dc=addrbook,dc=clr"): bi_db_open failed! (1) 57581a99 slapd shutdown: initiated 57581a99 ==>backsql_db_close() 57581a99 <==backsql_db_close() 57581a99 slapd destroy: freeing system resources. 57581a99 ==>backsql_close_db_handle(0x20445f0) 57581a99 <==backsql_close_db_handle(0x20445f0) 57581a99 ==>backsql_db_destroy() 57581a99 ==>backsql_free_db_env() 57581a99 <==backsql_free_db_env() 57581a99 ==>destroy_schema_map() 57581a99 <==destroy_schema_map() 57581a99 <==backsql_db_destroy() 57581a99 slapd stopped. # tail -f /var/lib/mysql/server_audit.log 20160608 15:58:08,cleared_hostname,l,localhost,688,0,CONNECT,,,0 20160608 15:58:08,cleared_hostname,l,localhost,688,3786,QUERY,,'SET NAMES utf8',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3787,QUERY,,'SET character_set_results = NULL',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3788,QUERY,,'SET SQL_AUTO_IS_NULL = 0',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3789,QUERY,,'SET AUTOCOMMIT=0',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3790,QUERY,,'set @@sql_select_limit=DEFAULT',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3791,QUERY,,'S',1064 <<<<<<<< RIGHT HERE <<<<<<<< 20160608 15:58:08,cleared_hostname,l,localhost,68873792,QUERY,,'ROLLBACK',0 20160608 15:58:08,cleared_hostname,l,localhost,688,0,DISCONNECT,,,0

1 0

Re: (ITS#8303) An Asynchronous meta back-end - some fixes
by hyc＠symas.com 07 Jun '16

07 Jun '16

nivanova(a)symas.com wrote: > Some new bug fixes for asyncmeta: ITS#8303 was already resolved, these patches should be in a new ticket. > 1.Fix for a crash during an add operation > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_01.patch > 2. Asyncmeta ignored ors_tlimit if operation timeout was configured > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_02.patch > 3. Fixed uninitialized control value during copy of operation, which > caused occasional crashes when controls without values are used. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_03.patch > 4. Fixed a missing result message if onerr=continue and the last result > is an error. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_04.patch > 5. Fixed incorrect copy of the entry of an add operation, which resulted > in memory leaks. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_05.patch > > Best Regards, > Nadezhda Ivanova > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8303) An Asynchronous meta back-end - some fixes
by nivanova＠symas.com 07 Jun '16

07 Jun '16

Some new bug fixes for asyncmeta: 1.Fix for a crash during an add operation ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_01.patch 2. Asyncmeta ignored ors_tlimit if operation timeout was configured ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_02.patch 3. Fixed uninitialized control value during copy of operation, which caused occasional crashes when controls without values are used. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_03.patch 4. Fixed a missing result message if onerr=continue and the last result is an error. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_04.patch 5. Fixed incorrect copy of the entry of an add operation, which resulted in memory leaks. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_05.patch Best Regards, Nadezhda Ivanova

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs