openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6428) modification to global limits require a restart to take effect
by rhafer＠suse.de 10 Dec '09

10 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.231.132) Changes to the global limits in "olcDatabase=frontend,cn=config" don't take effect database until slapd is restarted. I am working on a fix.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 10 Dec '09

10 Dec '09

I have now installed openldap 2.4.19 from source (default configuration except for --enable-crypt=yes). # slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ But unfortunately, the bug is still there. Nothing has changed at all.. It has crashed 10 times since I did the migration 10 hours ago. It usually crashes 1-2 times at night, and 10-20 times during work hours (when the servers have more load). When I migrated, I recreated the database by typing: # oldbin/slapcat > db.ldif # newbin/slapadd < db.ldif # (under the new openldap/slapd user) So I can't imagine the database can be corrupt in any way, which I initially thought when I first sent this bug report. It still dies on the same queries as before, in the middle of iterating through ou=users,.. or ou=groups,.., which both have ~1.8k entries. These queries comes from proftpd, which does a "getent passwd" and "getent group" every time a customer logs in. I tried to reproduce this manually again, launching 8 processes, constantly querying ou=users and ou=groups, 2 using a unix socket locally and 6 using ldaps://hostname/ remotely, but it still won't break down when I do that. This causes *alot* more load than proftpd does, but the crashes seem to only happen "randomly". Any suggestions on what I can do to figure out this problem? The LDAP server is live and in use in two servers with 2-3k users, so I can't mess with it *too* much. On Fri, Oct 02, 2009 at 09:28:25PM +0000, quanah(a)zimbra.com wrote: >--On Friday, October 02, 2009 8:54 PM +0000 hyc(a)symas.com wrote: > > >> strace is useless. Use gdb and get a trace of all running threads when >> this occurs. >> >> http://www.openldap.org/faq/data/cache/59.html > > >You also need to test against a current release of OpenLDAP, like OpenLDAP >2.4.18. > >--Quanah > > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration > > -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 10 Dec '09

10 Dec '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> The problem is that back-relay presents slapo-rwm(3) an entry with both >> REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a >> consequence, the entry is released (namely, freed) before it is returned >> by the frontend. As far as I understand, the two flags should be mutually >> exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is >> supposed to be a copy of an entry that may need to be released, or an >> entry created from scratch and thus not stored anywhere. I have a quick >> fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when >> REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in >> tracking where the issue occurs. Unless I track it, I'll commit the quick >> fix. > > We already have ITS#5340 for issues with these flags... Right. I asked him to open an ITS because I though the error was in slapo-rwm; my first fix was in that area. Soon after, I realized the error was in slapo-dynlist, related to ITS#5340. p.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 10 Dec '09

10 Dec '09

I wrote: > Otherwise it should use rs_ensure_entry_modifiable(). Currently > it's still wrong: Discards the old entry without obeying sr_flags. Unless dynlist_sc_save_entry() handles it, I haven't yet tried to figure out the state when it is called. But it looks wrong: it saves and clears rs->sr_entry without saving/clearing (rs->sr_flags & REP_ENTRY_MASK). Here is a draft for what rs_ensure_entry_modifiable() usage is supposed to look like, though I haven't tested it well and I'm going home now. I'm unsure of the translucent code. rwm looks a bit weird, but that's mostly to assert that some functions that receive rs won't modify it. I haven't touched dynlist, don't know what entry ownership is there. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft.diff -- Hallvard

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

ldapwhoami has the same behaviour [root@ldap1 ~]# time ldapwhoami -xZZh ldap1.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m4.835s user 0m0.021s sys 0m0.012s [root@ldap1 ~]# time ldapwhoami -xZZh ldap2.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m0.042s user 0m0.023s sys 0m0.013s

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

I've been trying to do too much at once in this ITS. My macros can be simplified to at least use functions for the exposed API. Since we now have commits related to this (ITS#6423), there's no reason not to use a common function for the new commits, instead of trying to get it right each time. I've committed a variant of this, so far unused: slap.h REP_ENTRY_MUSTFLUSH, result.c rs_replace_entry(), rs_ensure_entry_modifiable() When an overlay can wants to update rs->sr_entry it can use these. Exception: Some code may want to temporarily replace the entry and later restore it. That should be by a push/pop of sr_entry and (sr_flags & REP_ENTRY_MASK) together. That is, push: <save rs->sr_entry and rs->rs_flags>; rs->sr_flags &= ~REP_ENTRY_MASK; rs->sr_entry = new entry; rs->sr_flags |= new entryflags, if any; pop: rs_replace_entry(op, rs, on, <old entry>); rs->sr_flags |= (<saved flags> & REP_ENTRY_MASK); Maybe this is what dynlist.c:dynlist_prepare_entry() wants to do? I don't see why else it waits to the end of the function to set rs->sr_flags/sr_entry to the _new_ flags and entry. Otherwise it should use rs_ensure_entry_modifiable(). Currently it's still wrong: Discards the old entry without obeying sr_flags. I don't know what overlay to pass to entry_modifiable though. -- Hallvard

1 0

(ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 09 Dec '09

09 Dec '09

Full_Name: Pavel Lisy Version: 2.4.19 or 2.4.20 OS: linux - CentOS4/5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.132.159.239) I have my rpm built on source from Fedora 12. ldapsearch have delay on start, slapd is heavy loaded (up to 90% proc) on the same machine over TLS/SSL only (numbers below) [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m2.610s user 0m0.029s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-z.log 2>&1 real 0m2.700s user 0m0.026s sys 0m0.013s [root@ldap1 ~]# time ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search.log 2>&1 real 0m0.021s user 0m0.010s sys 0m0.008s [root@ldap1 ~]# time ldapsearch24 -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2.log 2>&1 real 0m0.027s user 0m0.009s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-z.log 2>&1 real 0m0.070s user 0m0.028s sys 0m0.020s [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-zz.log 2>&1 real 0m0.048s user 0m0.026s sys 0m0.017s This means: delay is there when I query from the same machine over TLS/SSL, not across machines. I suppose it is bug but I cannot find where it is. When I've changed in slapd.conf "loglevel 0" to "loglevel 1" delay is gone [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m0.315s user 0m0.030s sys 0m0.025s When I start ldapsearch24 through strace delay was in part with stars: ------------ cut --------------- munmap(0x2b2edf8b1000, 4096) = 0 brk(0x15747000) = 0x15747000 write(2, "TLS trace: SSL_connect:before/co"..., 53TLS trace: SSL_connect:before/connect initialization ) = 53 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4 fstat(4, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0 poll([{fd=4, events=POLLIN}], 1, 10) = 1 ([{fd=4, revents=POLLIN}]) read(4, "D~j?,\274k\310mx\336\t\17k\207Q\322\0369SDB\260\241bd6[R}6\201"..., 48) = 48 close(4) = 0 getuid() = 0 write(3, "\200t\1\3\1\0K\0\0\0 \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 118 *********************************************** DELAY 2s HERE *********************************************** ) = 118 write(2, "TLS trace: SSL_connect:SSLv2/v3 "..., 53TLS trace: SSL_connect:SSLv2/v3 write client hello A ) = 53 read(3, "\26\3\1\0J\2\0", 7) = 7 read(3, "\0F\3\1K \10\5\232\0\3\2\354\235\351\233\276\31\242\302\217\214\35\32\370cGH\342\277\7;"..., 72) = 7 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 49TLS trace: SSL_connect:SSLv3 read server hello A ) = 49 read(3, "\26\3\1\6\303", 5) = 5 read(3, "\v\0\6\277\0\6\274\0\2\2500\202\2\2440\202\2\r\2\3\20\0\0010\r\6\t*\206H\206\367"..., 1731) = 1731 write(2, "TLS certificate verification: de"..., 191TLS certificate verification: depth: 1, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS certificate verification: de"..., 146TLS certificate verification: depth: 0, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 55TLS trace: SSL_connect:SSLv3 read server certificate A ) = 55 read(3, "\26\3\1\0\4", 5) = 5 read(3, "\16\0\0\0", 4) = 4 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 48TLS trace: SSL_connect:SSLv3 read server done A ) = 48 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 57TLS trace: SSL_connect:SSLv3 write client key exchange A ) = 57 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 56TLS trace: SSL_connect:SSLv3 write change cipher spec A ) = 56 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 46TLS trace: SSL_connect:SSLv3 write finished A ) = 46 write(3, "\26\3\1\0\206\20\0\0\202\0\200\202\365\233\356\r\26\27\330\251\17\330\331\3362\23\231\211`\\\262\32 write(2, "TLS trace: SSL_connect:SSLv3 flu"..., 40TLS trace: SSL_connect:SSLv3 flush data ) = 40 read(3, "\24\3\1\0\1", 5) = 5 read(3, "\1", 1) = 1 read(3, "\26\3\1\0000", 5) = 5 read(3, "\353;\20\337y\307&\331\207@#\265\314\267\240\244\177P\223\216\221\216!\"G \27\265R\3078l"..., 48) = write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 45TLS trace: SSL_connect:SSLv3 read finished A ) = 45 write(2, "ldap_sasl_bind\n", 15ldap_sasl_bind ) = 15 write(2, "ldap_send_initial_request\n", 26ldap_send_initial_request ) = 26 write(2, "ldap_send_server_request\n", 25ldap_send_server_request ) = 25 write(2, "ber_scanf fmt ({it) ber:\n", 25ber_scanf fmt ({it) ber: ) = 25 write(2, "ber_scanf fmt ({i) ber:\n", 24ber_scanf fmt ({i) ber: ) = 24 write(2, "ber_flush2: 44 bytes to sd 3\n", 29ber_flush2: 44 bytes to sd 3 ) = 29 write(3, "\27\3\1\0 \217\244v\31\275A\232=\300\357\330\312*\316)\311\23\242\260\350n\353\373\221\204B\v"..., write(2, "ldap_result ld 0x156816c0 msgid "..., 34ldap_result ld 0x156816c0 msgid 2 ) = 34 write(2, "wait4msg ld 0x156816c0 msgid 2 ("..., 50wait4msg ld 0x156816c0 msgid 2 (infinite timeout) ) = 50 write(2, "wait4msg continue ld 0x156816c0 "..., 46wait4msg continue ld 0x156816c0 msgid 2 all 1 ) = 46 write(2, "** ld 0x156816c0 Connections:\n", 30** ld 0x156816c0 Connections: ) = 30 write(2, "* host: ldap1.ldapnet.tmapy.cz "..., 53* host: ldap1.ldapnet.tmapy.cz port: 389 (default) ) = 53 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected ) = 31 write(2, " last used: Wed Dec 9 21:26:51"..., 39 last used: Wed Dec 9 21:26:51 2009 ------------ cut --------------- How can I debug it more? I will send more details if you want.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 09 Dec '09

09 Dec '09

--On Wednesday, December 09, 2009 12:56 PM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: 2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > Bus error > [root@dc1 openldap]# Please provide a GDB backtrace of the crash with full debugging symbols. Thanks --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

hyc(a)symas.com writes: > We already have ITS#5340 for issues with these flags... I'll follow up there. Looking again, I think it can be simplified. -- Hallvard

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 09 Dec '09

09 Dec '09

On 12/08/2009 07:31 PM, masarati(a)aero.polimi.it wrote: > Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 > > Please test and report. Thanks, p. Thanks! At least the dynlist overlay works fine now. (Couldn't test slapo-collect and slapo-overlay.) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria

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