- openldap-bugs - openldap.org

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Pierangelo Masarati wrote: > Should be fixed in HEAD. Please test. p. Nope. Synced head, make distclean and re-installed. But still it does not start (see log below). slapd.conf contains: overlay dds dds-state true dds-max-ttl 86400 dds-min-ttl 1 dds-default-ttl 3600 dds-interval 60 dds-tolerance 0 dds-max-dynamicObjects 100 Ciao, Michael. ----------------------------------------------------------------------- backend_startup_one: starting "cn=accesslog,dc=block-floete,dc=de" bdb_db_open: database "cn=accesslog,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/accesslog). backend_startup_one: starting "ou=odd2006,dc=block-floete,dc=de" hdb_db_open: database "ou=odd2006,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/bv). put_filter: "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z))" put_filter: AND put_filter_list "(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z)" put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" put_filter: "(entryExpireTimestamp<=20071208175929Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=20071208175929Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=0 put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS non-expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated ====> bdb_cache_release_all ==> unique_close ====> bdb_cache_release_all slapd-odd2006 destroy: freeing system resources. ==> unique_db_destroy slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: (ITS#5269) few glitches in man pages
by hyc＠symas.com 08 Dec '07

08 Dec '07

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.3.39 > OS: > URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch > Submission from: (NULL) (82.224.237.5) > > > Some options are missing in command synopsys, while documented in available > options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R > authcid for ldappasswd). Submitted patch fix the issue. Thanks for the patch. -P should be invalid for ldapwhoami since it uses an extended operation, and those are not supported in LDAPv2. -- -- 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#5269) few glitches in man pages
by Guillaume.Rousse＠inria.fr 08 Dec '07

08 Dec '07

Full_Name: Guillaume Rousse Version: 2.3.39 OS: URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch Submission from: (NULL) (82.224.237.5) Some options are missing in command synopsys, while documented in available options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R authcid for ldappasswd). Submitted patch fix the issue.

1 0

(ITS#5268) dSAOperation attributes should not be replicated
by hyc＠OpenLDAP.org 08 Dec '07

08 Dec '07

Full_Name: Howard Chu Version: HEAD/RE24/RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Operational attributes like auditContext and contextCSN that are specific to a particular DSA should never be replicated. It may make sense to add a check in slap_send_search_entry to skip all dSAOperation attributes at that point. That would catch all instances, but it would mean they were generated needlessly by whatever code manages the attribute. For now, patching accesslog.c and syncprov.c seems more useful.

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

Should be fixed in HEAD. Please test. p. 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#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

> bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") > => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") > <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found > (-30989) > send_ldap_result: conn=-1 op=0 p=0 > DDS expired objects lookup failed err=32 Makes sense to skip searching for expired entries in a non existing database... p. 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

(ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.18) Situation: 1. slapo-dds is defined for database ou=odd2006,dc=block-floete,dc=de in slapd.conf 2. entry ou=odd2006,dc=block-floete,dc=de does not yet exist => slapd does not start (see log below). For the ease of initial setup I'd prefer that slapd would start. bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... >>> (dbx) print assertDN->bv_val >>> assertDN->bv_val = (nil) >>> >>> don't do that... As I suspected, there's more wrong here than a bad printf argument. The assertDN should never be NULL. -- -- 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#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... Yes, understood. That characteristic of Solaris hasn't changed. But test044 in HEAD exercises code that hasn't been included in RE24, and I was focusing on RE24. -- -- 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#5264) invalid printf of NULL
by richton＠nbcs.rutgers.edu 07 Dec '07

07 Dec '07

"./run test044" is sufficient to reproduce 100% of the time. Maybe the behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can remember... On Fri, 7 Dec 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > > -- > -- 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#5109) ldap_int_global_options not initialized
by lighthousej＠gmail.com 07 Dec '07

07 Dec '07

------=_Part_13800_24934559.1197042335995 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries. I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program. The code seems to want to copy an array of strings which contain attributes from the global variable. The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string. The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine. I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. ------=_Part_13800_24934559.1197042335995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries. I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program. The code seems to want to copy an array of strings which contain attributes from the global variable.  The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string.  The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine. I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. ------=_Part_13800_24934559.1197042335995--

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

hyc(a)symas.com wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? Never mind, I'm testing RE24, not HEAD. This part of dynlist isn't present in RE24. > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > -- -- 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#5259) SIGSEGV in slap_auxprop_store during SASL/OTP bind
by hyc＠symas.com 07 Dec '07

07 Dec '07

dwhite(a)olp.net wrote: > Full_Name: Dan White > Version: 2.3.39 > OS: Linux > URL: http://support.olp.net/ldap/log.txt > Submission from: (NULL) (65.161.252.42) Nice bit of debugging there. This could be a bit tricky because the slapd auxprop code assumes it's always executing on behalf of an LDAP operation (usually a Bind request). In this case, there is no active request; it's the cleanup action on a closed connection, and most of the state that slapd needed has already been torn down. It may take some restructuring to allow this to work, we never expected sasl_dispose() to be anything other than a pure destructor. > I'm experiencing crashes in slapd when attempting to bind via SASL using the OTP > mech. > > I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). > I'm using the bdb backend. > > I'm also using Debian Etch with the following versions of software: > > Cyrus SASL 2.1.22(.dfsg1-8) > libdb 4.2.52(+dfsg-2) > libc6 2.3.6(.ds1-13etch2) > > I've compiled cyrus sasl to use it's internal implementation of OTP, rather than > OPIE: > > --enable-otp > (--with-opie is not enabled) > > The problem I'm experiencing isn't when I successfully authenticate; that seems > to work fine. It's when I run an ldapsearch, but instead of entering an OTP > password, I press ctrl-c to cancel the search. > >>From the shell, when I perform an LDAP search, all appears normal: > > hiro:~# ldapsearch -Y OTP -U abrown(a)olp.net > SASL/OTP authentication started > Challenge: otp-md5 497 hi3182 ext > Please enter your one-time password:<ctrl-c> > hiro:~# > > However my slapd process dies. > > Here's a gdb backtrace of the server process: > > ... > Core was generated by `/usr/sbin/slapd'. > Program terminated with signal 11, Segmentation fault. > #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, > prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) > at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 > 478 op.o_hdr = > conn->c_sasl_bindop->o_hdr; > (gdb) bt > #0 0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0, > prctx=0x82351c0, user=0x820a148 "abrown(a)olp.net", ulen=14) > at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478 > #1 0xb7eb17d7 in sasl_auxprop_store () from /usr/lib/libsasl2.so.2 > #2 0xb7973c89 in otp_server_plug_init () from /usr/lib/sasl2/libotp.so.2 > #3 0xb7ebde36 in sasl_server_new () from /usr/lib/libsasl2.so.2 > #4 0xb7eb6194 in sasl_dispose () from /usr/lib/libsasl2.so.2 > #5 0x080b2992 in slap_sasl_close (conn=0xb7ec3618) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:1331 > #6 0x0806cf27 in connection_close (c=0xb75b1148) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:715 > #7 0x0806e116 in connection_read (s=12) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:1458 > #8 0x0806a49f in slapd_daemon_task (ptr=0x0) at > /usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/daemon.c:2468 > #9 0xb7cd3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #10 0xb7c674ae in clone () from /lib/tls/i686/cmov/libc.so.6 > (gdb) quit > > I've added a debug statement within slap_auxprop_store, so the openldap debug > information below will include some additional information about what's being > modified. > > The output can be obtained from: > > http://support.olp.net/ldap/log.txt > > Notice the two lines: > > Dec 3 13:39:06 hiro slapd[11134]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0499^Ihi5935^I0e81b33e30182715^I00000000001196711046. > Dec 3 13:39:07 hiro slapd[11134]: slap_auxprop_store [conn=-1]: Getting ready > to set cmusaslsecretOTP to > md5^I0499^Ihi5935^I0e81b33e30182715^I00000000000000000000. > > If I enter a good OTP password, I get this in my logs: > > Dec 3 13:43:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0499^Ihi5865^Iec8123986aec6550^I00000000001196711306. > Dec 3 13:44:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. > > If I enter an incorrect password, I get this: > > Dec 3 13:45:21 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000001196711421. > Dec 3 13:45:22 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to > set cmusaslsecretOTP to > md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000. > > So in the case where it's crashing, it appears the Cyrus SASL is attempting to > revert the OTP entry back to the previous version to "unlock" it. I assume that > the connection id of '-1' is relevant to the crash. -- -- 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#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: HEAD > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.137) In a separate email you mentioned that you ran into this problem in test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly did you get this to occur? > [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = > 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" > > 1660 struct berval base = BER_BVNULL; > 1661 > 1662 sm.dn = assertDN; > 1663 sm.match = 0; > 1664 cb.sc_private = &sm; > 1665 > 1666 Debug( LDAP_DEBUG_TRACE, > 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", > 1668 assertDN->bv_val, rule->bv_val, 0 ); > 1669 > 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ > > (dbx) print assertDN->bv_val > assertDN->bv_val = (nil) > > don't do that... > > > . > -- -- 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#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 06 Dec '07

06 Dec '07

--=-ENBDdr/KGkLnrgJWYt0i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: > db_stat -CA I've run this on all the databases. It seems clear to me the issue is with the 'user' db. [abartlet@naomi source]$ cd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/user [abartlet@naomi user]$ db_stat -CA Default locking region information: 16 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 7 Number of current locks 11 Maximum number of locks at any one time 17 Number of current lockers 18 Maximum number of lockers at any one time 6 Number of current lock objects 9 Maximum number of lock objects at any one time 73 Total number of locks requested 66 Total number of locks released 0 Total number of locks upgraded 8 Total number of locks downgraded 1 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3005 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/205 0% 360/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D16 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D15 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D14 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D13 locks held 0 write locks 0 pid/thread 347/1090525520 =20 5 dd=3D12 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D11 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D10 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 8 dd=3D 9 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 8 locks held 1 write locks 0 pid/thread 347/1090525520 =20 9 READ 1 HELD 0x59310 len: 9 data: 0x010000000000000000 a dd=3D 7 locks held 0 write locks 0 pid/thread 347/1107310928 =20 b dd=3D 6 locks held 1 write locks 0 pid/thread 347/1090525520 =20 b READ 1 HELD objectClass.bdb handle 0 c dd=3D 5 locks held 0 write locks 0 pid/thread 347/1090525520 =20 d dd=3D 4 locks held 0 write locks 0 pid/thread 347/1090525520 =20 e dd=3D 3 locks held 1 write locks 0 pid/thread 347/1090525520 =20 e READ 1 HELD objectCategory.bdb handle 0 f dd=3D 2 locks held 0 write locks 0 pid/thread 347/1090525520 =20 10 dd=3D 1 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8000000b dd=3D 0 locks held 1 write locks 1 pid/thread 347/1090525520 =20 8000000b WRITE 1 WAIT 0x59310 len: 9 data: 0x010000000000000000 8000000b WRITE 1 HELD id2entry.bdb page 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 8000000b WRITE 1 HELD id2entry.bdb page 1 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 b READ 1 HELD objectClass.bdb handle 0 e READ 1 HELD objectCategory.bdb handle 0 9 READ 1 HELD 0x59310 len: 9 data: 0x010000000000000000 8000000b WRITE 1 WAIT 0x59310 len: 9 data: 0x010000000000000000 [abartlet@naomi schema]$ pwd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/schema [abartlet@naomi schema]$ db_stat -CA Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 2 Number of current locks 4 Maximum number of locks at any one time 9 Number of current lockers 9 Maximum number of lockers at any one time 2 Number of current lock objects 4 Maximum number of lock objects at any one time 31 Total number of locks requested 29 Total number of locks released 0 Total number of locks upgraded 4 Total number of locks downgraded 0 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3016 allocations, 0 failures, 11 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/96 0% 363/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1098918224 =20 5 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1098918224 =20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 [abartlet@naomi config]$ pwd /home/data/samba/samba4/SAMBA_4_0/source/st/dc/private/ldap/db/config [abartlet@naomi config]$ db_stat -CA Default locking region information: 9 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 2 Number of current locks 4 Maximum number of locks at any one time 9 Number of current lockers 9 Maximum number of lockers at any one time 2 Number of current lock objects 4 Maximum number of lock objects at any one time 31 Total number of locks requested 29 Total number of locks released 0 Total number of locks upgraded 4 Total number of locks downgraded 0 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 0 The number of region locks that required waiting (0%) =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aaaaabef000 Original region address 0x2aaaaabef000 Region address 0x2aaaaabef068 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3016 allocations, 0 failures, 11 frees, 1 longest REGION_JOIN_OK Region flags =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock region parameters: 163 Lock region region mutex [0/96 0% 366/46912496263136] 1031 locker table size 1031 object table size 584 obj_off 54296 locker_off 0 need_dd =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Lock conflict matrix: 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 1 READ 1 HELD id2entry.bdb handle 0 2 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 3 dd=3D 0 locks held 1 write locks 0 pid/thread 347/46912500832560 =20 3 READ 1 HELD dn2id.bdb handle 0 4 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1115703632 =20 5 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 6 dd=3D 0 locks held 0 write locks 0 pid/thread 347/46912500832560 =20 7 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 8 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1090525520 =20 9 dd=3D 0 locks held 0 write locks 0 pid/thread 347/1115703632 =20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-ENBDdr/KGkLnrgJWYt0i Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD4DBQBHWLFwz4A8Wyi0NrsRAsZVAJi3+Vq41t9uwEfIKjzPFyzEUIOBAJ9B744l fc4tt0W/CKELwgwaxKzTxw== =5an3 -----END PGP SIGNATURE----- --=-ENBDdr/KGkLnrgJWYt0i--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by quanah＠zimbra.com 06 Dec '07

06 Dec '07

db_stat is a tool that's part of BDB. you need the version compiled with the same version of BDB slapd is linked against. --Quanah --On December 7, 2007 2:24:10 AM +0000 abartlet(a)samba.org wrote: > > --=-/HF725u21l3Qb11U+0ES > Content-Type: multipart/mixed; boundary="=-MG7wif63bfoyDI2pqs1S" > > > --=-MG7wif63bfoyDI2pqs1S > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > > On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: >> Andrew Bartlett wrote: >> > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: >> >> This stack trace looks a little funny, but I think this should be >> >> fixe= > d now in >> >> HEAD. >> > =20 >> > BTW, this is on Fedora 8, x86_64. >> > =20 >> > ldd shows: >> > libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) >> > =20 >> > I see no positive change so far. Current backtrace looks identical to >> > me: >> =20 >> Ok, we'll also need to see the relevant config info then.=20 > > Attached.=20 > >> Also it would be=20 >> interesting to see the output from db_stat -CA. > > Is this a tool I should build in the OpenLDAP tree - I can't otherwise > find it on my system. > > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > slapd_db_stat to match, for 4.4).=20 > > Andrew Bartlett > > --=20 > Andrew Bartlett > http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Red Hat Inc. > > --=-MG7wif63bfoyDI2pqs1S > Content-Disposition: attachment; filename=slapd.conf > Content-Type: text/plain; name=slapd.conf; charset=utf-8 > Content-Transfer-Encoding: base64 > > bG9nbGV2ZWwgMA0KDQppbmNsdWRlIC9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRfM > C9z > b3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2JhY2tlbmQtc2NoZW1hLnNjaGVtYQ0KDQpwaWRma > Wxl > CQkvaG9tZS9kYXRhL3NhbWJhL3NhbWJhNC9TQU1CQV80XzAvc291cmNlL3N0L2RjL3ByaXZhd > GUv > bGRhcC9zbGFwZC5waWQNCmFyZ3NmaWxlCS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBX > zRf > MC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL3NsYXBkLmFyZ3MNCnNhc2wtcmVhbG0gc2FtY > mEu > ZXhhbXBsZS5jb20NCmFjY2VzcyB0byAqIGJ5ICogd3JpdGUNCg0KYWxsb3cgdXBkYXRlX2Fub > 24N > Cg0KYXV0aHotcmVnZXhwDQogICAgICAgICAgdWlkPShbXixdKiksY249c2FtYmEuZXhhbXBsZ > S5j > b20sY249ZGlnZXN0LW1kNSxjbj1hdXRoDQogICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQ > z1l > eGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2NvdW50TmFtZT1cJDEpDQoNCmF1dGh6LXJlZ2V4c > A0K > ICAgICAgICAgIHVpZD0oW14sXSopLGNuPShbXixdKiksY249ZGlnZXN0LW1kNSxjbj1hdXRoD > Qog > ICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY > 2Nv > dW50TmFtZT1cJDEpDQoNCmluY2x1ZGUgL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfN > F8w > L3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvbW9kdWxlcy5jb25mDQoNCmRlZmF1bHRzZWFyY > 2hi > YXNlIERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQoNCmJhY2tlbmQJCWhkYg0KZGF0YWJhc > 2Ug > ICAgICAgIGJkYg0Kc3VmZml4CQlDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iY > SxE > Qz1leGFtcGxlLERDPWNvbQ0KZGlyZWN0b3J5CS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBT > UJB > XzRfMC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2RiL3NjaGVtYQ0KaW5kZXggICAgICAgI > CAg > IG9iamVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZ > GV4 > IG5hbWUgZXENCmluZGV4IG9iamVjdENhdGVnb3J5IGVxDQppbmRleCBsREFQRGlzcGxheU5hb > WUg > ZXENCmluZGV4IHN1YkNsYXNzT2YgZXENCg0KZGF0YWJhc2UgICAgICAgIGhkYg0Kc3VmZml4C > QlD > Tj1Db25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpkaXJlY3RvcnkJL > 2hv > bWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkY > XAv > ZGIvY29uZmlnDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgZXENCmluZGV4ICAgICAgI > CAg > ICBzYW1BY2NvdW50TmFtZSBlcQ0KaW5kZXggbmFtZSBlcQ0KaW5kZXggb2JqZWN0U2lkIGVxD > Qpp > bmRleCBvYmplY3RDYXRlZ29yeSBlcQ0KaW5kZXggbkNOYW1lIGVxDQppbmRleCBzdWJDbGFzc > 09m > IGVxDQppbmRleCBkbnNSb290IGVxDQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQpkYXRhYmFzZ > SAg > ICAgICAgaGRiDQpzdWZmaXgJCURDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpyb290ZG4gI > CAg > ICAgICAgY249TWFuYWdlcixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbQ0Kcm9vdHB3ICAgI > CAg > ICAgIGxvY2FsZGNwYXNzDQpkaXJlY3RvcnkJL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQ > kFf > NF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvZGIvdXNlcg0KaW5kZXggICAgICAgICAgI > G9i > amVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4I > G5h > bWUgZXENCmluZGV4IG9iamVjdFNpZCBlcQ0KaW5kZXggb2JqZWN0Q2F0ZWdvcnkgZXENCmluZ > GV4 > IG1lbWJlciBlcQ0KaW5kZXggdWlkTnVtYmVyIGVxDQppbmRleCBnaWROdW1iZXIgZXENCmluZ > GV4 > IHVuaXhOYW1lIGVxDQppbmRleCBwcml2aWxlZ2UgZXENCmluZGV4IG5DTmFtZSBlcQ0KaW5kZ > Xgg > bERBUERpc3BsYXlOYW1lIGVxDQppbmRleCBzdWJDbGFzc09mIGVxDQppbmRleCBkbnNSb290I > GVx > DQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQojc3luY3Byb3YgaXMgc3RhYmxlIGluIE9wZW5MR > EFQ > IDIuMywgYW5kIGF2YWlsYWJsZSBpbiAyLjIuICANCiNXZSBvbmx5IG5lZWQgdGhpcyBmb3Igd > Ghl > IGNvbnRleHRDU04gYXR0cmlidXRlIGFueXdheS4uLi4NCm92ZXJsYXkgc3luY3Byb3YNCnN5b > mNw cm92LWNoZWNrcG9pbnQgMTAwIDEwDQpzeW5jcHJvdi1zZXNzaW9ubG9nIDEwMA0K > > > --=-MG7wif63bfoyDI2pqs1S > Content-Disposition: attachment; filename=modules.conf > Content-Type: text/plain; name=modules.conf; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > > --=-MG7wif63bfoyDI2pqs1S-- > > --=-/HF725u21l3Qb11U+0ES > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQBHWK7Cz4A8Wyi0NrsRAjkmAJ0bTTeKP2f5Fx9jUUbzRuzSp8VxbACgnwOk > zmJTUTdITBffKjjCbgZwazo= > =yB+p > -----END PGP SIGNATURE----- > > --=-/HF725u21l3Qb11U+0ES-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 06 Dec '07

06 Dec '07

--=-/HF725u21l3Qb11U+0ES Content-Type: multipart/mixed; boundary="=-MG7wif63bfoyDI2pqs1S" --=-MG7wif63bfoyDI2pqs1S Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 18:09 -0800, Howard Chu wrote: > Andrew Bartlett wrote: > > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: > >> This stack trace looks a little funny, but I think this should be fixe= d now in > >> HEAD. > >=20 > > BTW, this is on Fedora 8, x86_64. > >=20 > > ldd shows: > > libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) > >=20 > > I see no positive change so far. Current backtrace looks identical to > > me: >=20 > Ok, we'll also need to see the relevant config info then.=20 Attached.=20 > Also it would be=20 > interesting to see the output from db_stat -CA. Is this a tool I should build in the OpenLDAP tree - I can't otherwise find it on my system. I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a slapd_db_stat to match, for 4.4).=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-MG7wif63bfoyDI2pqs1S Content-Disposition: attachment; filename=slapd.conf Content-Type: text/plain; name=slapd.conf; charset=utf-8 Content-Transfer-Encoding: base64 bG9nbGV2ZWwgMA0KDQppbmNsdWRlIC9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRfMC9z b3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2JhY2tlbmQtc2NoZW1hLnNjaGVtYQ0KDQpwaWRmaWxl CQkvaG9tZS9kYXRhL3NhbWJhL3NhbWJhNC9TQU1CQV80XzAvc291cmNlL3N0L2RjL3ByaXZhdGUv bGRhcC9zbGFwZC5waWQNCmFyZ3NmaWxlCS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJBXzRf MC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL3NsYXBkLmFyZ3MNCnNhc2wtcmVhbG0gc2FtYmEu ZXhhbXBsZS5jb20NCmFjY2VzcyB0byAqIGJ5ICogd3JpdGUNCg0KYWxsb3cgdXBkYXRlX2Fub24N Cg0KYXV0aHotcmVnZXhwDQogICAgICAgICAgdWlkPShbXixdKiksY249c2FtYmEuZXhhbXBsZS5j b20sY249ZGlnZXN0LW1kNSxjbj1hdXRoDQogICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1l eGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2NvdW50TmFtZT1cJDEpDQoNCmF1dGh6LXJlZ2V4cA0K ICAgICAgICAgIHVpZD0oW14sXSopLGNuPShbXixdKiksY249ZGlnZXN0LW1kNSxjbj1hdXRoDQog ICAgICAgICAgbGRhcDovLy9EQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT8/c3ViPyhzYW1BY2Nv dW50TmFtZT1cJDEpDQoNCmluY2x1ZGUgL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8w L3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvbW9kdWxlcy5jb25mDQoNCmRlZmF1bHRzZWFyY2hi YXNlIERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQoNCmJhY2tlbmQJCWhkYg0KZGF0YWJhc2Ug ICAgICAgIGJkYg0Kc3VmZml4CQlDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxE Qz1leGFtcGxlLERDPWNvbQ0KZGlyZWN0b3J5CS9ob21lL2RhdGEvc2FtYmEvc2FtYmE0L1NBTUJB XzRfMC9zb3VyY2Uvc3QvZGMvcHJpdmF0ZS9sZGFwL2RiL3NjaGVtYQ0KaW5kZXggICAgICAgICAg IG9iamVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4 IG5hbWUgZXENCmluZGV4IG9iamVjdENhdGVnb3J5IGVxDQppbmRleCBsREFQRGlzcGxheU5hbWUg ZXENCmluZGV4IHN1YkNsYXNzT2YgZXENCg0KZGF0YWJhc2UgICAgICAgIGhkYg0Kc3VmZml4CQlD Tj1Db25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpkaXJlY3RvcnkJL2hv bWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFfNF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAv ZGIvY29uZmlnDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgZXENCmluZGV4ICAgICAgICAg ICBzYW1BY2NvdW50TmFtZSBlcQ0KaW5kZXggbmFtZSBlcQ0KaW5kZXggb2JqZWN0U2lkIGVxDQpp bmRleCBvYmplY3RDYXRlZ29yeSBlcQ0KaW5kZXggbkNOYW1lIGVxDQppbmRleCBzdWJDbGFzc09m IGVxDQppbmRleCBkbnNSb290IGVxDQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQpkYXRhYmFzZSAg ICAgICAgaGRiDQpzdWZmaXgJCURDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tDQpyb290ZG4gICAg ICAgICAgY249TWFuYWdlcixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbQ0Kcm9vdHB3ICAgICAg ICAgIGxvY2FsZGNwYXNzDQpkaXJlY3RvcnkJL2hvbWUvZGF0YS9zYW1iYS9zYW1iYTQvU0FNQkFf NF8wL3NvdXJjZS9zdC9kYy9wcml2YXRlL2xkYXAvZGIvdXNlcg0KaW5kZXggICAgICAgICAgIG9i amVjdENsYXNzIGVxDQppbmRleCAgICAgICAgICAgc2FtQWNjb3VudE5hbWUgZXENCmluZGV4IG5h bWUgZXENCmluZGV4IG9iamVjdFNpZCBlcQ0KaW5kZXggb2JqZWN0Q2F0ZWdvcnkgZXENCmluZGV4 IG1lbWJlciBlcQ0KaW5kZXggdWlkTnVtYmVyIGVxDQppbmRleCBnaWROdW1iZXIgZXENCmluZGV4 IHVuaXhOYW1lIGVxDQppbmRleCBwcml2aWxlZ2UgZXENCmluZGV4IG5DTmFtZSBlcQ0KaW5kZXgg bERBUERpc3BsYXlOYW1lIGVxDQppbmRleCBzdWJDbGFzc09mIGVxDQppbmRleCBkbnNSb290IGVx DQppbmRleCBuRVRCSU9TTmFtZSBlcQ0KDQojc3luY3Byb3YgaXMgc3RhYmxlIGluIE9wZW5MREFQ IDIuMywgYW5kIGF2YWlsYWJsZSBpbiAyLjIuICANCiNXZSBvbmx5IG5lZWQgdGhpcyBmb3IgdGhl IGNvbnRleHRDU04gYXR0cmlidXRlIGFueXdheS4uLi4NCm92ZXJsYXkgc3luY3Byb3YNCnN5bmNw cm92LWNoZWNrcG9pbnQgMTAwIDEwDQpzeW5jcHJvdi1zZXNzaW9ubG9nIDEwMA0K --=-MG7wif63bfoyDI2pqs1S Content-Disposition: attachment; filename=modules.conf Content-Type: text/plain; name=modules.conf; charset=us-ascii Content-Transfer-Encoding: quoted-printable --=-MG7wif63bfoyDI2pqs1S-- --=-/HF725u21l3Qb11U+0ES Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHWK7Cz4A8Wyi0NrsRAjkmAJ0bTTeKP2f5Fx9jUUbzRuzSp8VxbACgnwOk zmJTUTdITBffKjjCbgZwazo= =yB+p -----END PGP SIGNATURE----- --=-/HF725u21l3Qb11U+0ES--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 06 Dec '07

06 Dec '07

Andrew Bartlett wrote: > On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: >> This stack trace looks a little funny, but I think this should be fixed now in >> HEAD. > > BTW, this is on Fedora 8, x86_64. > > ldd shows: > libdb-4.6.so => /lib64/libdb-4.6.so (0x000000353ac00000) > > I see no positive change so far. Current backtrace looks identical to > me: Ok, we'll also need to see the relevant config info then. Also it would be interesting to see the output from db_stat -CA. -- -- 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#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 06 Dec '07

06 Dec '07

--=-vArXI+WqUCu1GDzWcahr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-12-06 at 05:34 -0800, Howard Chu wrote: > This stack trace looks a little funny, but I think this should be fixed n= ow in=20 > HEAD. BTW, this is on Fedora 8, x86_64. ldd shows: libdb-4.6.so =3D> /lib64/libdb-4.6.so (0x000000353ac00000) I see no positive change so far. Current backtrace looks identical to me: (gdb) thread apply all bt Thread 6 (Thread 1082132816 (LWP 30533)): #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042af8a in ?? () #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1090525520 (LWP 30536)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:582 #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1098918224 (LWP 30538)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so #6 0x00000000004c55bf in hdb_cache_entry_db_relock () #7 0x00000000004c5d60 in hdb_cache_modify () #8 0x00000000004a03cd in hdb_modify () #9 0x0000000000500666 in ?? () #10 0x00000000005009b2 in ?? () #11 0x000000000043bd45 in ?? () #12 0x000000000043e55f in ?? () #13 0x000000000043f188 in slap_send_ldap_result () #14 0x00000000004c32ad in hdb_add () #15 0x00000000004888d2 in overlay_op_walk () #16 0x0000000000488dd5 in ?? () #17 0x0000000000434407 in fe_op_add () #18 0x0000000000434c0c in do_add () #19 0x000000000042ddb6 in ?? () #20 0x000000000042e24d in ?? () #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 ---Type <return> to continue, or q <return> to quit--- #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1107310928 (LWP 30539)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so #5 0x00000000004c5424 in ?? () #6 0x00000000004c6c09 in hdb_cache_find_id () #7 0x00000000004ca14b in hdb_dn2entry () #8 0x00000000004a3ce0 in hdb_referrals () #9 0x00000000004888d2 in overlay_op_walk () #10 0x0000000000488dd5 in ?? () #11 0x0000000000438fc0 in backend_check_referrals () #12 0x00000000004342ab in fe_op_add () #13 0x0000000000434c0c in do_add () #14 0x000000000042ddb6 in ?? () #15 0x000000000042e24d in ?? () #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1115703632 (LWP 30540)): #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000353ac28a2d in __db_pthread_mutex_lock () from /lib64/libdb-4.6.so #2 0x000000353ac2866f in __db_tas_mutex_lock () from /lib64/libdb-4.6.so #3 0x000000353ac9136d in __lock_get_internal () from /lib64/libdb-4.6.so #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so #5 0x00000000004c5424 in ?? () #6 0x00000000004c6c09 in hdb_cache_find_id () #7 0x00000000004ca14b in hdb_dn2entry () #8 0x00000000004a3ce0 in hdb_referrals () #9 0x00000000004888d2 in overlay_op_walk () #10 0x0000000000488dd5 in ?? () ---Type <return> to continue, or q <return> to quit--- #11 0x0000000000438fc0 in backend_check_referrals () #12 0x0000000000443ac6 in fe_op_modify () #13 0x0000000000444476 in do_modify () #14 0x000000000042ddb6 in ?? () #15 0x000000000042e24d in ?? () #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=3D0x845530) at tpool.c:625 #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 Thread 1 (Thread 46912500832560 (LWP 30530)): #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000428cd2 in slapd_daemon () #2 0x0000000000418549 in main () #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-vArXI+WqUCu1GDzWcahr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHWIVLz4A8Wyi0NrsRAhIaAJ9diePymzMaec/iazOApBBqT5LorwCeMZyO ifzef9jmBkp9/ZDDn9y+VKY= =4wdf -----END PGP SIGNATURE----- --=-vArXI+WqUCu1GDzWcahr--

1 0

Re: (ITS#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Note: This ITS need not hold up 2.4.7; the tests fail in 2.4.6 too. I wrote: > "./run -b ldif test004-modify" gets noSuchObject when it attempts to > delete "cn=James A Jones 2,ou=Information Technology Division, > ou=People,dc=example,dc=com". The same happens in test008-concurrency. The ldapsearch output contains 4 entries that should have been deleted: dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com dn: cn=James A Jones 3,ou=Alumni Association,ou=People,dc=example,dc=com dn: cn=James A Jones 4,ou=People,dc=example,dc=com dn: cn=James A Jones 5,dc=example,dc=com The Delete operations for those got noSuchObject, but further Binds as them succeed. (At least in spot checks of Joneses #3 and #4.) slapd-addel.c contains #if 0'ed out code /* wait a second for the add to really complete */ /* This masks some race conditions though. */ sleep( 1 ); The program's Add and Delete calls are synchronous, so I'm not sure what that is about. In any case, it made no difference to put a random 0-15 second sleep there (so the slapd-addel processes would delete at different times). While I'm checking this - other tests that fail with back-ldif: test027-emptydn [cannot slapadd to a database with suffix ""] Unsupported operations, I guess: test016-subref test017-syncreplication-refresh test025-limits [didn't bump into server-side unchecked limit] test037-manage OK failure - compare fails because of entry order from ldapsearch: test012-glue-populate test026-dn test004, test008 and test017 succeed in 2.3.38. Maybe the fix to ITS#4627 (back-ldif issues) was bad? -- Regards, Hallvard

1 0

Can't compile OpenLDAP with Berkekey DB: File format not recognized
by ben＠fallinganvils.com 06 Dec '07

06 Dec '07

This is my first openldap install. I am installing by compiling from source on a debian box logged in as myself in my home directory. Berkeley DB is not installed systemwide. LDAP libraries are installed systemwide, but I want to install the whole openldap tarball in my home directory and use that/run an ldap server etc. Only libraries are installed systemwide. No ldap server software is installed systemwide. I do have root access, but I don't think I should need it. If I can get it installed under /home/ben, after some experimentation, I'll install it in /home/openldap after creating an openldap user. I don't know what the debian system uses the ldap libraries it came with for, but I should be able to use my own local version without dealing with that I would think. This is what I do : 1) Install Berkeley DB 4.6.21 in /home/ben/opt/bdb $ cd db-4.6.21/build_unix $ ../dist/configure --prefix=/home/ben/opt/bdb $ make && make install $ export LD_RUN_PATH=/home/ben/opt/bdb/lib $ export CPPFLAGS='-I /home/ben/opt/bdb/include' $ export LDFLAGS='-L /home/ben/opt/bdb/lib' $ cd 2) Install OpenLDAP $ cd openldap-2.4.6 $ ./configure --prefix=/home/ben/opt/openldap $ make depend $ make Making all in /home/ben/src/openldap/openldap-2.4.6 Entering subdirectory include make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/include' Entering subdirectory libraries make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries' Making all in /home/ben/src/openldap/openldap-2.4.6/libraries Entering subdirectory liblutil make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' /bin/sh ../..//libtool --mode=link cc -static -g -O2 -L /home/ben/opt/bdb/lib -o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv cc -g -O2 /home/ben/opt/bdb/lib -o dtest dtest.o -L/home/ben/src/openldap/openldap-2.4.6/libraries/liblber ./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv /usr/bin/ld: /home/ben/opt/bdb/lib: No such file: File format not recognized collect2: ld returned 1 exit status make[2]: *** [dtest] Error 1 make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries' make: *** [all-common] Error 1 3) Let's investigate: $ ls /home/ben/opt/bdb bin docs include lib $ ls -l /home/ben/opt/bdb/lib -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb-4.6.a -rw-r--r-- 1 ben ben 813 Nov 28 21:44 libdb-4.6.la -rwxr-xr-x 1 ben ben 1248813 Nov 28 21:44 libdb-4.6.so lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb-4.so -> libdb-4.6.so -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb.a lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb.so -> libdb-4.6.so $ vi libdb-4.6.a The first bit looks like: !<arch> / 1196286289 0 0 0 27970 ` ^@^@^E0^@^@m\xea^@^@m\xea^@^@m\xea^@^@m\xea^@^@u"^@^@ Not sure what that means, but someone might... $ vi libdb-4.so The first bit looks like: ^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^C^@^C^@^A^@^@^@\xf0i^A^@4^@^@^@x\xde^Q^@^@^@^@^@4^ @ ^@^D^@(^@^_^@^\^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@\xe8\x85^Q^@\xe8 Hey! more nonsense, but ELF is familiar and seems like a plausable for a linux library... I also get this error with openldap-2.3.39 and db-4.5.20 I could not use openldap-2.3.39 with db-4.6.21 because I get incompatible version. The configure scripts looks for db versions 4.2 though 4.5 and spits out that error otherwise. Anyway, thanks for any help.

2 1

(ITS#5266) "authorization failure: invalid authcid" during SASL auto_transition
by dwhite＠olp.net 06 Dec '07

06 Dec '07

Full_Name: Dan White Version: 2.3.39 OS: Linux URL: http://support.olp.net/ldap/log2.txt Submission from: (NULL) (65.161.252.42) If I enable SASL auto_transition, I receive the following error during authentication: SASL(-14): authorization failure: invalid authcid I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). I'm using the bdb backend. I'm also using Debian Etch with the following versions of software: Cyrus SASL 2.1.22(.dfsg1-8) libdb 4.2.52(+dfsg-2) libc6 2.3.6(.ds1-13etch2) PAM 0.79(-4) pam_ldap 184(-2) I'm using saslauthd's PAM backend, and in turn using pam_ldap for authentication, although I don't believe the problem is related to the saslauthd/pam configuration. Here's the client side output from the attempted bind: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: ldap_sasl_interactive_bind_s: Insufficient access (50) additional info: SASL(-14): authorization failure: invalid authcid If I turn off auto_transition, it works: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: SASL username: abrown(a)olp.net SASL SSF: 0 hiro:~# My slapd.conf SASL service file looks like: hiro:~# cat /usr/lib/sasl2/slapd.conf keytab: /etc/krb5.keytab-ldap pwcheck_method: saslauthd auxprop_plugin: slapd auto_transition: yes log_level: 7 And the server log (loglevel -1) is located at: http://support.olp.net/ldap/log2.txt The error appears to be occurring while transitioning the password to the auxprop store, in the slap_sasl_authorize function: /* Skip SLAP_SASL_PROP_CONN */ prop_getnames( props, slap_propnames+1, auxvals ); /* Should not happen */ if ( !auxvals[0].values ) { sasl_seterror( sconn, 0, "invalid authcid" ); return SASL_NOAUTHZ; } What I'm expecting to happen during the bind, is to have SASL overwrite my userPassword and cmusaslsecretOTP attributes, via the slapd auxprop plugin. I have a lot of passwords in crypted form (which PAM authenticates), and I'm aiming towards a clear-text password store by using this functionality.

1 0

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

hyc(a)symas.com writes: > As I recall, the only reason we needed the waking counter here was to > make sure we never filled the pipe buffer, which would cause a > single-threaded server to deadlock. We can simply set the pipe to > nonblocking instead, and eliminate the counter. Sounds good... > The other point was that if there was already a pending wake event, > there was no reason to write another one. Aha! Now the code makes more sense to me:-) And if 'waking' is just a boolean flag, we can keep it as long as it is treated that way. #define WAKE_LISTENER(w) do { \ if ((w) && !waking) { \ waking = 1; \ tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \ } \ } while (0) I need to stare at it a bit to look for race conditions with readers. I don't suggest to hold next RE24 for this though. It's hardly urgent, and should be tested a bit --without-threads first. -- Regards, Hallvard

1 0

(ITS#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/test004bug.tbz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test004-modify" gets noSuchObject when it attempts to delete "cn=James A Jones 2,ou=Information Technology Division, ou=People,dc=example,dc=com". The tests do not fully support back-ldif, but I don't see why this one should fail. The entry is present as testrun/db.1.a/dc=example,dc=com/ou=people/ou=information technology division/cn=james a jones 2.ldif. tests$ ./run -b ldif test004-modify Cleaning up test run directory leftover from previous run. Running ./scripts/test004-modify... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd modify operations... Testing modify, add, and delete... ldapmodify failed (32)! tests$ grep '^conn=' testrun/slapd.1.log | tail -n6 conn=1 op=6 do_delete conn=1 op=6 DEL dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" conn=1 op=6 RESULT tag=107 err=32 text= conn=1 op=7 do_unbind conn=1 op=7 UNBIND conn=1 fd=8 closed

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 06 Dec '07

06 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Fixed the easy cases in HEAD. > WAKE_LISTENER under --without-threads remains. > As I recall, the only reason we needed the waking counter here was to make sure we never filled the pipe buffer, which would cause a single-threaded server to deadlock. We can simply set the pipe to nonblocking instead, and eliminate the counter. The other point was that if there was already a pending wake event, there was no reason to write another one. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs