openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#7085) mutex lockup issue
by quanah＠zimbra.com 02 Dec '11

02 Dec '11

--On Friday, December 02, 2011 11:41 AM -0500 Soichi Hayashi <hayashis(a)indiana.edu> wrote: > Quanah, > > > Were you able to recreate this issue? > Hi Soichi, I have not even attempted to reproduce it. I will see if I have time in my lab to do so. However, I use BDB 5.2.28. I will note that the backtrace you provided is useless, since you apparently did not build your binaries with debugging symbols, which is always advised. I also don't know what optimization level you used, but I strongly advise against building optimized OpenLDAP builds, gcc rarely does the right thing. Finally, OpenLDAP doesn't use select() on Linux platforms, it uses poll() which appears to be what you're backtrace indicates as well. Since you don't have debugging symbols enabled, it's virtually impossible to determine where the problem is originating. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7085) mutex lockup issue
by hayashis＠indiana.edu 02 Dec '11

02 Dec '11

--0016364c7ac7fff89504b31ea350 Content-Type: text/plain; charset=ISO-8859-1 Quanah, Were you able to recreate this issue? Soichi On Wed, Nov 16, 2011 at 3:56 PM, Soichi Hayashi <hayashis(a)indiana.edu>wrote: > Quanah, > > We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 > hours into our testing in similar manner to what I have reported earlier. I > believe this issue still occurs on the latest version. > > However, when I used gdb, I didn't notice the mutex locked threads like I > did with OpenLDAP 2.4.22. > > Following is from locked 2.4.26 slapd server. > > (gdb) info thread > 14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait () > from /lib64/libc.so.6 > 13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > 3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from > /lib64/libc.so.6 > 2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 > () from /lib64/libpthread.so.0 > * 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join > () from /lib64/libpthread.so.0 > (gdb) thread 3 > [Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0 > 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 > #1 0x000000000054ece5 in ?? () > #2 0x000000000054aa15 in ?? () > #3 0x0000000000557637 in ?? () > #4 0x0000000000557c11 in ?? () > #5 0x00000000004b2d93 in ?? () > #6 0x00000000004e9d7c in ?? () > #7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0 > #8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6 > > It looks like it's waiting on select() on thread 3 which never get fired > when I access it using ldapsearch command. > > I ran strace on ldapsearch (on a client machine) and following is what I > see at the end of the log.. > > $ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b > mds-vo-name=WT2,o=grid > "(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))" > > .... > write(1, "\n", 1 > ) = 1 > write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110 > poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1 > > Not sure if this strace is useful or not.. but after this, ldapsearch > never returned. > > Thanks, > Soichi > > > On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > >> --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote: >> >> Full_Name: Soichi Hayashi >>> Version: 2.4.22 >>> >> >> OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a >> current release (2.4.26). This report will not be investigated unless you >> can reproduce it with a current release of OpenLDAP. You also fail to note >> what BDB release you are using, and whether or not it has all the relevant >> patches applied to it. If you have a broken policy of only using vendor >> provided packages, then you will need to send a bug report to RedHat, as it >> is their job to maintain their vendor packages. >> >> >> Thanks! >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > > --0016364c7ac7fff89504b31ea350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quanah,<div><br></div><div>Were you able to recreate this issue?</div><div>= <br></div><div>Soichi<br><div><br><div class=3D"gmail_quote">On Wed, Nov 16= , 2011 at 3:56 PM, Soichi Hayashi <span dir=3D"ltr"><<a href=3D"mailto:h= ayashis(a)indiana.edu">hayashis(a)indiana.edu</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div>Quanah,</div><div><br></div><div>We ha= ve compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 hours= into our testing in similar manner to what I have reported earlier. I beli= eve this issue still occurs on the latest version.</div> <div><br></div><div>However, when I used gdb, I didn't notice the mutex= locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F= ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div> (gdb) info thread</div> <div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa= it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) = =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp= thread.so.0</div> <div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre= ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC= _2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa= d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_= 2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread= 0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread= 0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread = 0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s= o.6</div> <div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x= 2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib= 64/libpthread.so.0</div> <div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW= P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><= div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li= bc.so.6</div> <div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i= n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000= 00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>= #6 =A00x00000000004e9d7c in ?? ()</div> <div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.= 0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div= ><div><br></div><div>It looks like it's waiting on select() on thread 3= which never get fired when I access it using ldapsearch command.=A0</div> <div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo= llowing is what I see at the end of the log..</div><div><br></div><div>$ st= race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg= rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))= "</div> <div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "= 0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di= v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div> <div><br></div><div>Not sure if this strace is useful or not.. but after th= is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S= oichi</div><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div><br><div = class=3D"gmail_quote"> On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<= a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah(a)zimbra.com</a>= ></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Wednesday, November 09, 2011 2:01 PM +0= 000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@indi= ana.edu</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Soichi Hayashi<br> Version: 2.4.22<br> </blockquote> <br> OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a= current release (2.4.26). =A0This report will not be investigated unless y= ou can reproduce it with a current release of OpenLDAP. =A0You also fail to= note what BDB release you are using, and whether or not it has all the rel= evant patches applied to it. =A0If you have a broken policy of only using v= endor provided packages, then you will need to send a bug report to RedHat,= as it is their job to maintain their vendor packages.<br> <br> <br> Thanks!<span><font color=3D"#888888"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></span></blockquote></div><br> </div></div></blockquote></div><br></div></div> --0016364c7ac7fff89504b31ea350--

1 0

Re: (ITS#6962) Download down?
by h.b.furuseth＠usit.uio.no 30 Nov '11

30 Nov '11

h.b.furuseth(a)usit.uio.no writes: >demian.djrn(a)gmail.com writes: >> all mirrors are down, i can't download the program. > > The mirror list needs to be updated. These are down or obsolete: > > Costa Rica: No /openldap directory. Still missing in the directory listing at <http://mirrors.ucr.ac.cr/>. > Italy: Unknown host it.openldap.org. > Korea: No route to host ftp.holywar.net; TTL exceeded. > Portugal: Last update was in 2008. I notice these have been removed from the mirror list now. -- Hallvard

1 0

(ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by dieter＠dkluenter.de 30 Nov '11

30 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

(ITS#7101) test001 no longer supports back-ldif
by h.b.furuseth＠usit.uio.no 29 Nov '11

29 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.4.28 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard test001-slapadd now breaks with back-ldif, since it uses unordered slapadd which back-ldif does not support. Also 'rm -f $DBDIR1/*' should be 'rm -rf' for back-ldif.

1 0

Re: (ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by hyc＠symas.com 29 Nov '11

29 Nov '11

nick(a)eurobjects.com wrote: > Full_Name: Nikolaos Milas > Version: 2.4.26 (LTB RPM) > OS: CentOS 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.251.204.222) > > > We use the following schema (among others): Thanks for the report, this is now fixed in git master. > > DN: cn={5}postfix,cn=schema,cn=config > objectClass: olcSchemaConfig > cn: {5}postfix > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC > 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A > flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) > olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC > 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $ > mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) ) > olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual > account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid > $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) ) > olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email > account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY ( > mailacceptinggeneralid $ aliasInactive ) ) > olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox > for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description ) > > We run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > > where /root/work/schemachange1: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC > 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > This is successful: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > modify complete > > However, then we try to run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > > where /root/work/schemachange2: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the > address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > and this causes an OpenLDAP crash: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > > This hangs, and we interrupt with Ctrl-C. > > gdb reports: -- -- 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#7099) slapadd segfaults with back-mdb and slapo-dds
by hyc＠symas.com 29 Nov '11

29 Nov '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.38.5.243) > > > back-mdb tries to read entry databases prior to initialisation, which leeds to > segmatation fault slapo-dds was misbehaving, fixed now in master. Overlays that hook the db_open entry point are required to check for (slapMode & SLAP_TOOL_MODE) and exit as a no-op in that case. slapo-dds was not doing this. It caused slapcat to crash as well. This problem was triggered by using the dds-max_dynamocObjects setting, which makes slapo-dds fire off a search at startup to find entries to expire/delete. Of course this operation fails in slapcat anyway, since the database is opened read-only. > > output of slapadd -d-1 > [...] > 4ed4888e slapadd startup: initiated. > 4ed4888e backend_startup_one: starting "o=avci,c=de" > 4ed4888e mdb_db_open: "o=avci,c=de" > 4ed4888e mdb_db_open: database "o=avci,c=de": > dbenv_open(/home/dieter/openldap/var/ldap-dds). > 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" > 4ed4888e begin get_filter > 4ed4888e AND > 4ed4888e begin get_filter_list > 4ed4888e begin get_filter > 4ed4888e EQUALITY > 4ed4888e end get_filter 0 > 4ed4888e begin get_filter > 4ed4888e LE > 4ed4888e end get_filter 0 > 4ed4888e end get_filter_list > 4ed4888e end get_filter 0 > Speicherzugriffsfehler > > the appropriate slapo-dds configuration: > [...] > overlay dds > dds-max-ttl 86400 > dds-min-ttl 0 > dds-default-ttl 3600 > dds-interval 1800 > dds-tolerance 60 > dds-max-dynamicObjects 100 > dds-state TRUE > [...] > > -Dieter > > -- -- 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#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Pierangelo Masarati wrote: > Good point. I overlooked this in my original interpretation. I'll look into > this, time permitting. Thanks, p. Take your time. Nothing urgent. I'm just playing with it for interop testing (refresh operation and plugin classes in web2ldap). Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by masarati＠aero.polimi.it 29 Nov '11

29 Nov '11

On 11/29/2011 02:34 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.15.82) > > > As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a > dynamicObject entry. But slapo-dds always returns the same value for entryTTL > (last refreshTTL). Another server implementation returns decreasing values for > entryTTL which would be IMO the correct behaviour. Good point. I overlooked this in my original interpretation. I'll look into this, time permitting. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.15.82) As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a dynamicObject entry. But slapo-dds always returns the same value for entryTTL (last refreshTTL). Another server implementation returns decreasing values for entryTTL which would be IMO the correct behaviour.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs