openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#4915) Syncrepl task exits are not logged
by unix.gurus＠gmail.com 06 Apr '07

06 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) It is hard to tell when the syncrepl task has exited. The attached patch adds logging of syncrepl hard and soft failures. Using this patch, it is easier to spot unfortunate conditions where recoverable failures are treated as hard failures, for example the third line below shows that a (temporarily) unavailable kerberos credential cache causes a hard failure: GSSAPI Error: Miscellaneous failure (No credentials cache found) do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) do_syncrepl: rid 123 hard failure Hmm, no attachment because the FTP server returns: 200 PORT command successful. 150 Opening ASCII mode data connection for 'openldap-2.3.32-syncrepl-log-failure.patch'. ## 452 Error writing file: No space left on device. 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) The patch was: *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 2007 --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 *************** *** 1147,1159 **** --- 1147,1169 ---- } if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d hard failure\n", + si->si_rid, 0, 0 ); ldap_pvt_runqueue_remove( &slapd_rq, rtask ); } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { if ( si->si_retrynum[i] > 0 ) si->si_retrynum[i]--; + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling (retries left: %d)\n", + si->si_rid, si->si_retrynum[i], 0 ); rtask->interval.tv_sec = si->si_retryinterval[i]; ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); slap_wake_listener(); + } else { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling\n", + si->si_rid, 0, 0 ); } }

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 06 Apr '07

06 Apr '07

------=_Part_45311_2874873.1175811229646 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/3/07, Howard Chu <hyc(a)symas.com> wrote: > The log says that ITS#4638 was already fixed in 2.3.32. Why are you > still using that particular patch, given that an alternate solution is > already present in the release? I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch). I also see that in RE23 we had one more patch to fix some interaction > between slapo-rwm and back-meta for filter processing. I suggest you > test against the current RE23 code. I expect to push 2.3.35 out pretty > soon. Thank you. Sean ------=_Part_45311_2874873.1175811229646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <span class="gmail_quote">On 4/3/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The log says that ITS#4638 was already fixed in 2.3.32. Why are you<br>still using that particular patch, given that an alternate solution is<br>already present in the release?</blockquote><div><br>I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also see that in RE23 we had one more patch to fix some interaction <br>between slapo-rwm and back-meta for filter processing. I suggest you<br>test against the current RE23 code. I expect to push 2.3.35 out pretty soon.</blockquote><div><br>Thank you. <br></div><br></div>Sean ------=_Part_45311_2874873.1175811229646--

1 0

Re: (ITS#4913) configure & BerkleyDB
by ando＠sys-net.it 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' Perhaps adding a "-" before "I" could help. Please check and report. > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem > > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. > > I set: > LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' > > But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. > > However, what the Oracle build procedure produces are: libdb-4.5.a > libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so > > Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. > > Nonetheless, it would be better if the 'configure' script were expanded to > gracefully handle this latest release of BerkeleyDB from Oracle. > > > > > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4913) configure & BerkleyDB
by hyc＠symas.com 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem If that's exactly what you used, you're missing the "-" in CPPFLAGS="-I..." > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. The configure script works perfectly fine with all 4.x releases of BerkeleyDB, including 4.6 which has not yet been publicly released. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4914) It's possible to add multiple config-Databases
by rhafer＠suse.de 05 Apr '07

05 Apr '07

Full_Name: Ralf Haferkamp Version: HEAD OS: Linux (Kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.70) Subject say it. You can add multiple olcDatabase=config Entries to the cn=config Backend. (With slapadd or through ldapadd) A fix is on the way to CVS. It will also make sure that olcDatabase=config always gets the Index 0.

1 0

(ITS#4913) configure & BerkleyDB
by fredo＠sundancer.us 05 Apr '07

05 Apr '07

Full_Name: Fred Obermann Version: 2.3.34 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.20.15.25) I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. There seems to be a disconnect between where openldap-2.3.34 'configure' expects db.h is and where Oracle's build procedure puts db.h. For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' does not seem to enable 'configure' to find 'db.h'. Providing soft link from /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this problem Furthermore there seems to be a disconnect between the Oracle naming convention for the BerkeleyDB libraries and what openldap's 'configure' utility seems to expect. I set: LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. However, what the Oracle build procedure produces are: libdb-4.5.a libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. Nonetheless, it would be better if the 'configure' script were expanded to gracefully handle this latest release of BerkeleyDB from Oracle.

1 0

Re: (ITS#4911) slapadd uses slap_op_mutex uninitialized
by hyc＠symas.com 05 Apr '07

05 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapadd uses slap_op_mutex uninitialized in operation.c:slap_op_time() Fixed. > Any hope of making the tools and slapd go through the same init/destroy code > in main(), maybe by making the server just another "tool"? Seems to me the > only hope of making bugs like this keep popping up... In the past the tools didn't use threads and didn't share as much code with slapd. As such, it seems a lot of subsystems really didn't need to be set up for tool mode. I guess things have changed since we now use Operation structures everywhere. Tools like slappasswd don't even read the slapd config. That means you can't use slappasswd with a dynamically loaded password-hash module. So yes, some of this structuring needs to be revisited. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#4910 mirrormode
by hyc＠symas.com 05 Apr '07

05 Apr '07

The mirrormode functionality has changed in 2.4.4 (compared to 2.4.3 and earlier) since full multimaster is now supported. You must set a unique serverID on each server to enable replication. See slapd-config(5) for the olcServerID config item. -- -- Howard Chu Chief Architect, 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#4912) test043 cores in bdb_locker_id_free()
by hyc＠symas.com 05 Apr '07

05 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test043 leaves behind two core files from a crash in bdb_locker_id_free(). Fixed. > > The test does succeed though. (Argh, I've got to dig up that test script > patch of mine, I don't even remember what the showstopper was anymore...) Would be nice to get that in. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4912) test043 cores in bdb_locker_id_free()
by h.b.furuseth＠usit.uio.no 04 Apr '07

04 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test043 leaves behind two core files from a crash in bdb_locker_id_free(). The test does succeed though. (Argh, I've got to dig up that test script patch of mine, I don't even remember what the showstopper was anymore...) >>>>> Starting test043-delta-syncrepl ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... ./scripts/test043-delta-syncrepl: line 130: 5697 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded ./scripts/test043-delta-syncrepl: line 356: 5715 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >>$LOG1 2>&1 >>>>> ./scripts/test043-delta-syncrepl completed OK. $ gdb ../servers/slapd/slapd core.5697 (the other crashes with the same backtrace) (gdb) thread apply all backtrace Thread 1 (process 5697): #0 0xdbdbdbdb in ?? () #1 0x08119e27 in bdb_locker_id_free (key=0x83536b0, data=0x7) at cache.c:1360 #2 0x0818e6ec in ldap_int_thread_pool_context_reset (vctx=0x8275160) at tpool.c:912 #3 0x081913a6 in ldap_pvt_thread_pool_context_reset (vctx=0x7) at thr_debug.c:1263 #4 0x080aad9f in slap_destroy () at init.c:271 #5 0x080670fb in main (argc=8, argv=0xbfffee84) at main.c:949 Configuration: CPPFLAGS='-DLDAP_REL_ENG -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' \ ./configure --prefix=/hbf/scratch/ldap/install/head \ --enable-crypt --enable-dynacl --enable-aci --enable-lmpasswd \ --enable-spasswd --enable-modules --enable-rlookups \ --enable-slapi --enable-slp --enable-wrappers \ --enable-backends --disable-sql --enable-overlays

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