openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

So, I followed your suggestion and set up the following config using overlay translucent: ... modulepath /opt/ldap/lib/ moduleload back_ldap moduleload back_bdb moduleload translucent ... backend bdb ... database bdb suffix "dc=CS,dc=EXAMPLE,dc=COM" readonly on directory "/var/lib/ldap" ... overlay translucent uri "ldaps://ORIG_SERVER_IP/" lastmod off translucent_no_glue ... The good news: it runs. The bad news: it doesn't do what I want :( "ldapsearch -x" dumps the full contents of the original (remote) server. But it doesn't give any of the entries in the local DB. If I take out the translucent directives, then "ldapsearch -x" does dump the contents of the local DB. >>> * I need to build a server that extends the contents of that server, for >>> the same domain; but I don't have access to the DB of that server. >> See slapo-translucent, which was written specifically for this reason. Re-reading the man page - it says: "Entries retrieved from a remote LDAP server may have some or all attributes overridden, or new attributes added, by entries in the local database before being presented to the client." However my local DB _extends_ the original server, that is: it adds _new entries_, as opposed to overriding attributes of existing entries. Again, this is why I selected the ldap-meta is the first place. Either that, or something has gone wrong with the configuration ? >> I would use back-ldap to contact the remote server and subordinate glue >> for the local bdb database. How would I go about the "subordinate glue" ? Oren. orenl(a)cs.columbia.edu wrote: > Hi, > > Howard Chu wrote: >> Oren Laadan wrote: >>>> It shows enough; back-meta is hanging waiting for responses from some >>>> other >>>> LDAP server. This is a pretty bad configuration; you should not use >>>> back-meta >>>> (or back-ldap) to redirect queries back into the same slapd. You >>>> should use >>>> back-relay instead. >>> I'm not quite sure why having the server query itself is such a bad idea. >>> Can you please explain ? >> Any request then occupies a minimum of two slapd threads - one for >> back-meta itself, and one for the extra inbound query. If you >> misconfigure the meta URIs then you get into an infinite loop, which >> consumes all of the available slapd threads. > > The URIs are configured as following (see my original ITS post > for the full config file): > > database meta > lastmod off > suffix "dc=CS,dc=EXAMPLE,dc=COM" > > uri "ldaps://ldap.cs.example.com/dc=CS,dc=EXAMPLE,dc=COM" > uri "ldaps:///dc=CS,dc=EXAMPLE,dc=COM" > suffixmassage "dc=CS,dc=EXAMPLE,dc=COM" "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >>> Let me repeat how my setup works: >>> >>> * there exists an LDAP server "ldap.cs.example.com" for domain >>> CS.EXAMPLE.COM >>> >>> * I need to build a server that extends the contents of that server, for >>> the same domain; but I don't have access to the DB of that server. >> See slapo-translucent, which was written specifically for this reason. > > I see. Am trying to build a new config using this overlay now. > >>> * My clients will use my server, with the domain CS.EXAMPLE.COM >>> (instead of >>> querying the original server) >> Please stop using the "domain" terminology. LDAP uses Distinguished >> Names, not domains. Tell us the distinguished names of the server >> contexts you're dealing with. Tell us the actual DNs of the entries >> you're dealing with. > > Yes are correct. I confuse the two terms because the DNs follow the > convention of the network domains. So -- > > the original server servers "dc=CS,dc=EXAMPLE,dc=COM" > my server serves the same DNs for the clients; however the "extra" > local DB that I created is set for "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >>> * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that >>> serves two >>> databases: >>> >>> (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very >>> small >>> database (less than 100 entries). >>> >>> (2) a META-backend for domain CS.EXAMPLE.COM that is configured to >>> relay >>> to both the original server (ldap.cs.example.com) and also relay >>> to the >>> local (other) server (ldap.mine.cs.example.com); the second relay >>> is done >>> with "suffixmassage" to convert from CS.EXAMPLE.COM to >>> MINE.CS.EXAMPLE.COM >>> and back. >>> >>> So, yes, my server/2nd-DB effectively relays queries to the my >>> server/1st-DB >>> The questions are: >>> >>> (1) why is this such a bad idea ? >> See above. >> >>> (2) how would I use back-ldap in place ? >> I would use back-ldap to contact the remote server and subordinate glue >> for the local bdb database. >> >>> Note that the reason to originally select the meta-ldap backend was >>> because >>> it was the only one that I could find in the docs that automagically >>> merges >>> two separate databases and presents them as a single database the client. >> I think you should be able to construct your DIT without needing to do >> any suffix massaging. >> > > The reason I needed the suffix massaging in my setup is because I had > two servers coexisting on the same machine: one that is used by the > clients, and one that is used by the server itself through ldap-meta; > > since the one visible to the clients was already "dc=CS,dc=EXAMPLE,dc=COM" > I had to make the other one do a different DN, hence the addition of > the "dc=MINE" at the beginning, and the suffix massaging > > I hope that overlay translucent works, and that it does away with this > ugly trick that I had to put there. > > I'm now re-doing the config to try it out. Many thanks to everybody > for the help so far. > > Oren. > >

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by ando＠sys-net.it 07 Feb '08

07 Feb '08

hyc(a)symas.com wrote: > Oren Laadan wrote: >>> It shows enough; back-meta is hanging waiting for responses from some other >>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>> (or back-ldap) to redirect queries back into the same slapd. You should use >>> back-relay instead. >> I'm not quite sure why having the server query itself is such a bad idea. >> Can you please explain ? > > Any request then occupies a minimum of two slapd threads - one for back-meta > itself, and one for the extra inbound query. If you misconfigure the meta URIs > then you get into an infinite loop, which consumes all of the available slapd > threads. Let me add that, moreover, any request is re-encoded as an LDAP request, sent to itself, re-decoded and re-processed by slapd. Back-relay directly relies the original, decoded request to another database, within the same thread. So it saves at least 3 resource-consuming steps- 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#5332) multimaster replication crash
by hyc＠symas.com 07 Feb '08

07 Feb '08

ghenry(a)suretecsystems.com wrote: > <quote who="Marcel Ritter"> >> Gavin Henry schrieb: >>> Marcel.Ritter(a)rrze.uni-erlangen.de wrote: >>>> Full_Name: Marcel Ritter >>>> Version: HEAD >>>> OS: Linux (openSUSE 10.3) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (131.188.78.179) >>>> When using multimaster replication slapd dies (on x86_64). >>>> >>>> I've used the scripts/test050-syncrepl-multimaster with one simple >>>> modification: I added one ldapadd command at the end of the script, >>>> trying to add some 20000 entries. >>>> >>> Have you tried this on a release, i.e. 2.4.7, not HEAD? >> Yes - I tried with 2.4.7 first. Then I asked Ralf Haferkamp from >> SuSE/Novell >> (he build's openldap 2.4 packages on the openSUSE Build Service) wether >> he had run some tests on this topic, but he declined and suggested to test >> with HEAD version. >> >> I tried this too, but to the same result. >> >> I've run my tests both on SuSE Linux Enterprise Server 10 and openSUSE >> 10.3. >> As far as I tested, this occurs only on x86_64 systems (i386 seems to >> get into >> an endless loop instead - but this may be for a different reason ...) I've seen the same crash while trying to add 10,000 entries. A patch for this is now in HEAD. I should point out that it's probably not getting into an endless loop. Just that this test wasn't designed to handle a large number of entries. None of the indexing that is normally recommended for syncrepl is set up in these configurations, so all of the search operations that syncrepl performs will wind up scanning the entire DB multiple times. Also the cache size remains at its default, so that will cause a lot of churn as you continue to operate on more entries. -- -- 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#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 07 Feb '08

07 Feb '08

Hi, Howard Chu wrote: > Oren Laadan wrote: >>> It shows enough; back-meta is hanging waiting for responses from some >>> other >>> LDAP server. This is a pretty bad configuration; you should not use >>> back-meta >>> (or back-ldap) to redirect queries back into the same slapd. You >>> should use >>> back-relay instead. >> >> I'm not quite sure why having the server query itself is such a bad idea. >> Can you please explain ? > > Any request then occupies a minimum of two slapd threads - one for > back-meta itself, and one for the extra inbound query. If you > misconfigure the meta URIs then you get into an infinite loop, which > consumes all of the available slapd threads. The URIs are configured as following (see my original ITS post for the full config file): database meta lastmod off suffix "dc=CS,dc=EXAMPLE,dc=COM" uri "ldaps://ldap.cs.example.com/dc=CS,dc=EXAMPLE,dc=COM" uri "ldaps:///dc=CS,dc=EXAMPLE,dc=COM" suffixmassage "dc=CS,dc=EXAMPLE,dc=COM" "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >> Let me repeat how my setup works: >> >> * there exists an LDAP server "ldap.cs.example.com" for domain >> CS.EXAMPLE.COM >> >> * I need to build a server that extends the contents of that server, for >> the same domain; but I don't have access to the DB of that server. > > See slapo-translucent, which was written specifically for this reason. I see. Am trying to build a new config using this overlay now. > >> * My clients will use my server, with the domain CS.EXAMPLE.COM >> (instead of >> querying the original server) > > Please stop using the "domain" terminology. LDAP uses Distinguished > Names, not domains. Tell us the distinguished names of the server > contexts you're dealing with. Tell us the actual DNs of the entries > you're dealing with. Yes are correct. I confuse the two terms because the DNs follow the convention of the network domains. So -- the original server servers "dc=CS,dc=EXAMPLE,dc=COM" my server serves the same DNs for the clients; however the "extra" local DB that I created is set for "dc=MINE,dc=CS,dc=EXAMPLE,dc=COM" > >> * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that >> serves two >> databases: >> >> (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very >> small >> database (less than 100 entries). >> >> (2) a META-backend for domain CS.EXAMPLE.COM that is configured to >> relay >> to both the original server (ldap.cs.example.com) and also relay >> to the >> local (other) server (ldap.mine.cs.example.com); the second relay >> is done >> with "suffixmassage" to convert from CS.EXAMPLE.COM to >> MINE.CS.EXAMPLE.COM >> and back. >> >> So, yes, my server/2nd-DB effectively relays queries to the my >> server/1st-DB >> The questions are: >> >> (1) why is this such a bad idea ? > > See above. > >> (2) how would I use back-ldap in place ? > > I would use back-ldap to contact the remote server and subordinate glue > for the local bdb database. > >> Note that the reason to originally select the meta-ldap backend was >> because >> it was the only one that I could find in the docs that automagically >> merges >> two separate databases and presents them as a single database the client. > > I think you should be able to construct your DIT without needing to do > any suffix massaging. > The reason I needed the suffix massaging in my setup is because I had two servers coexisting on the same machine: one that is used by the clients, and one that is used by the server itself through ldap-meta; since the one visible to the clients was already "dc=CS,dc=EXAMPLE,dc=COM" I had to make the other one do a different DN, hence the addition of the "dc=MINE" at the beginning, and the suffix massaging I hope that overlay translucent works, and that it does away with this ugly trick that I had to put there. I'm now re-doing the config to try it out. Many thanks to everybody for the help so far. Oren.

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 07 Feb '08

07 Feb '08

Quanah Gibson-Mount wrote: > --On Thursday, February 07, 2008 8:13 PM -0500 Oren Laadan > <orenl(a)cs.columbia.edu> wrote: > >> will fix the symbols now. thanks. >> >> as for the patch, it seems unrelated as it fixes a problem during the >> start-up of the daemon; also, it's for 2.4.7, and I just downgraded >> back to 2.4.49 (which I was using originally). the decision to move >> up was because I hoped that the problem would disappear when using a >> more recent version of openldap. as it turns out, it didn't :( > > > There's no such thing as 2.4.49. I assume you mean 2.3.40? Or 2.3.39? > I would use 2.3.40 over 2.3.39, and I would suggest doing your debugging yes.. typo ... s/4/3/g > with the OpenLDAP 2.4.7 release as it is unlikely there is going to be > any more 2.3 releases. Using 2.4 means your fix will actually get into > the next release. sure. just switched back to 2.4.7. > Also, please keep the ITS included in your replies. ok. Oren. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 07 Feb '08

07 Feb '08

Oren Laadan wrote: >> It shows enough; back-meta is hanging waiting for responses from some other >> LDAP server. This is a pretty bad configuration; you should not use back-meta >> (or back-ldap) to redirect queries back into the same slapd. You should use >> back-relay instead. > > I'm not quite sure why having the server query itself is such a bad idea. > Can you please explain ? Any request then occupies a minimum of two slapd threads - one for back-meta itself, and one for the extra inbound query. If you misconfigure the meta URIs then you get into an infinite loop, which consumes all of the available slapd threads. > Let me repeat how my setup works: > > * there exists an LDAP server "ldap.cs.example.com" for domain CS.EXAMPLE.COM > > * I need to build a server that extends the contents of that server, for > the same domain; but I don't have access to the DB of that server. See slapo-translucent, which was written specifically for this reason. > * My clients will use my server, with the domain CS.EXAMPLE.COM (instead of > querying the original server) Please stop using the "domain" terminology. LDAP uses Distinguished Names, not domains. Tell us the distinguished names of the server contexts you're dealing with. Tell us the actual DNs of the entries you're dealing with. > * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that serves two > databases: > > (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very small > database (less than 100 entries). > > (2) a META-backend for domain CS.EXAMPLE.COM that is configured to relay > to both the original server (ldap.cs.example.com) and also relay to the > local (other) server (ldap.mine.cs.example.com); the second relay is done > with "suffixmassage" to convert from CS.EXAMPLE.COM to MINE.CS.EXAMPLE.COM > and back. > > So, yes, my server/2nd-DB effectively relays queries to the my server/1st-DB > The questions are: > > (1) why is this such a bad idea ? See above. > (2) how would I use back-ldap in place ? I would use back-ldap to contact the remote server and subordinate glue for the local bdb database. > Note that the reason to originally select the meta-ldap backend was because > it was the only one that I could find in the docs that automagically merges > two separate databases and presents them as a single database the client. I think you should be able to construct your DIT without needing to do any suffix massaging. -- -- 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#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 07 Feb '08

07 Feb '08

This is a multi-part message in MIME format. --------------080905060502070406050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit sometimes it happens faster than other times ... here is another backtrace, this time with the symbols. Oren. hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> --On Thursday, February 07, 2008 6:56 PM -0500 Oren Laadan >> <orenl(a)cs.columbia.edu> wrote: >> >>> More threads, less threads -- it still happens :( >>> >>> Attached is the last part of the log before it stopped responding >>> (you can see towards the end the time gap). >>> >>> Also attached is the backtrace of all threads (thanks to gdb). >> Your backtrace is fairly useless. You need to do a make install STRIP="" >> so it doesn't strip the binaries on installation. Or copy over the slapd >> from your build area, as that is pre-stripping. Additionally, I'd add the >> patch from ITS#5341 to your build. >> >> Reading symbols from /usr/local/opt/ldap-2.4.7/libexec/slapd...(no >> debugging symbols found)...done. > > It shows enough; back-meta is hanging waiting for responses from some other > LDAP server. This is a pretty bad configuration; you should not use back-meta > (or back-ldap) to redirect queries back into the same slapd. You should use > back-relay instead. --------------080905060502070406050804 Content-Type: text/plain; name="ccc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ccc" LOCALHOST_ROOT:/var/log # gdb -p 982 GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". Attaching to process 982 Reading symbols from /usr/local/opt/ldap-2.3.39/libexec/slapd...done. Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". Reading symbols from /usr/local/opt/ldap-2.3.39/lib/libldap_r-2.3.so.0...done. Loaded symbols for /opt/ldap-2.3.39/lib/libldap_r-2.3.so.0 Reading symbols from /usr/local/opt/ldap-2.3.39/lib/liblber-2.3.so.0...done. Loaded symbols for /opt/ldap-2.3.39/lib/liblber-2.3.so.0 Reading symbols from /usr/lib/libdb-4.5.so...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /lib/i686/cmov/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xf7a5d6b0 (LWP 982)] [New Thread 0xf03ffb90 (LWP 998)] [New Thread 0xf1ed2b90 (LWP 997)] [New Thread 0xf27d4b90 (LWP 996)] [New Thread 0xf30d6b90 (LWP 995)] [New Thread 0xf39d8b90 (LWP 994)] [New Thread 0xf5addb90 (LWP 986)] [New Thread 0xf63dfb90 (LWP 985)] [New Thread 0xf6ce1b90 (LWP 984)] [New Thread 0xf74e2b90 (LWP 983)] Loaded symbols for /lib/i686/cmov/libpthread.so.0 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/i686/cmov/libdl.so.2...done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.8 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /lib/i686/cmov/libresolv.so.2...done. Loaded symbols for /lib/i686/cmov/libresolv.so.2 Reading symbols from /lib/i686/cmov/libc.so.6...done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/i686/cmov/libnss_files.so.2...done. Loaded symbols for /lib/i686/cmov/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/libdb-4.4.so...done. Loaded symbols for /usr/lib/libdb-4.4.so Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /lib/i686/cmov/libcrypt.so.1...done. Loaded symbols for /lib/i686/cmov/libcrypt.so.1 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 0xffffe405 in __kernel_vsyscall () (gdb) thread apply all bt Thread 10 (Thread 0xf74e2b90 (LWP 983)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b4af76 in epoll_wait () from /lib/i686/cmov/libc.so.6 #2 0x0805e8e6 in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #3 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #4 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 9 (Thread 0xf6ce1b90 (LWP 984)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x84c9710, timeout=0xf6cdfda0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x84c9710, msgid=42, all=2, timeout=0xf6ce00a0, result=0xf6ce00b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x878c2c8, rs=0xf6ce11c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x878c2c8, rs=0xf6ce11c4) at search.c:355 #6 0x0806455a in do_search (op=0x878c2c8, rs=0xf6ce11c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf6ce1248, arg_v=0x878c2c8) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 8 (Thread 0xf63dfb90 (LWP 985)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x87c00b8, timeout=0xf63ddda0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x87c00b8, msgid=42, all=2, timeout=0xf63de0a0, result=0xf63de0b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x878c0e8, rs=0xf63df1c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x878c0e8, rs=0xf63df1c4) at search.c:355 #6 0x0806455a in do_search (op=0x878c0e8, rs=0xf63df1c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf63df248, arg_v=0x878c0e8) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 7 (Thread 0xf5addb90 (LWP 986)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x87e05d0, timeout=0xf5adbda0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x87e05d0, msgid=42, all=2, timeout=0xf5adc0a0, result=0xf5adc0b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x8333730, rs=0xf5add1c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x8333730, rs=0xf5add1c4) at search.c:355 #6 0x0806455a in do_search (op=0x8333730, rs=0xf5add1c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf5add248, arg_v=0x8333730) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 ---Type <return> to continue, or q <return> to quit--- #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 6 (Thread 0xf39d8b90 (LWP 994)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x829eb88, timeout=0xf39d6da0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x829eb88, msgid=46, all=2, timeout=0xf39d70a0, result=0xf39d70b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x8356748, rs=0xf39d81c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x8356748, rs=0xf39d81c4) at search.c:355 #6 0x0806455a in do_search (op=0x8356748, rs=0xf39d81c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf39d8248, arg_v=0x8356748) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 5 (Thread 0xf30d6b90 (LWP 995)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x83788b8, timeout=0xf30d4da0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x83788b8, msgid=46, all=2, timeout=0xf30d50a0, result=0xf30d50b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x8333910, rs=0xf30d61c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x8333910, rs=0xf30d61c4) at search.c:355 #6 0x0806455a in do_search (op=0x8333910, rs=0xf30d61c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf30d6248, arg_v=0x8333910) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 4 (Thread 0xf27d4b90 (LWP 996)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0xf04a5d60, timeout=0xf27d2da0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0xf04a5d60, msgid=15, all=2, timeout=0xf27d30a0, result=0xf27d30b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x828c140, rs=0xf27d41c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x828c140, rs=0xf27d41c4) at search.c:355 #6 0x0806455a in do_search (op=0x828c140, rs=0xf27d41c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf27d4248, arg_v=0x828c140) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 3 (Thread 0xf1ed2b90 (LWP 997)): #0 0xffffe405 in __kernel_vsyscall () ---Type <return> to continue, or q <return> to quit--- #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0x83d3078, timeout=0xf1ed0da0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0x83d3078, msgid=42, all=2, timeout=0xf1ed10a0, result=0xf1ed10b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x83b6900, rs=0xf1ed21c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x83b6900, rs=0xf1ed21c4) at search.c:355 #6 0x0806455a in do_search (op=0x83b6900, rs=0xf1ed21c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf1ed2248, arg_v=0x83b6900) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 2 (Thread 0xf03ffb90 (LWP 998)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7b404c7 in poll () from /lib/i686/cmov/libc.so.6 #2 0xf7ef7555 in ldap_int_select (ld=0xf04a5820, timeout=0xf03fdda0) at os-ip.c:930 #3 0xf7ee3b41 in ldap_result (ld=0xf04a5820, msgid=15, all=2, timeout=0xf03fe0a0, result=0xf03fe0b4) at result.c:299 #4 0x080dbbe5 in meta_back_search (op=0x83451a0, rs=0xf03ff1c4) at search.c:1007 #5 0x08063c39 in fe_op_search (op=0x83451a0, rs=0xf03ff1c4) at search.c:355 #6 0x0806455a in do_search (op=0x83451a0, rs=0xf03ff1c4) at search.c:217 #7 0x08061ced in connection_operation (ctx=0xf03ff248, arg_v=0x83451a0) at connection.c:1133 #8 0xf7ee09ae in ldap_int_thread_pool_wrapper (xpool=0x81f3da0) at tpool.c:478 #9 0xf7d814fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xf7b4a75e in clone () from /lib/i686/cmov/libc.so.6 Thread 1 (Thread 0xf7a5d6b0 (LWP 982)): #0 0xffffe405 in __kernel_vsyscall () #1 0xf7d82775 in pthread_join () from /lib/i686/cmov/libpthread.so.0 #2 0xf7ee1294 in ldap_pvt_thread_join (thread=4149095312, thread_return=0x0) at thr_posix.c:193 #3 0x0805cc23 in slapd_daemon () at daemon.c:2579 #4 0x0804faa8 in main (argc=9, argv=0xff8a5594) at main.c:859 #0 0xffffe405 in __kernel_vsyscall () (gdb) --------------080905060502070406050804--

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by quanah＠zimbra.com 07 Feb '08

07 Feb '08

--On Thursday, February 07, 2008 8:13 PM -0500 Oren Laadan <orenl(a)cs.columbia.edu> wrote: > will fix the symbols now. thanks. > > as for the patch, it seems unrelated as it fixes a problem during the > start-up of the daemon; also, it's for 2.4.7, and I just downgraded > back to 2.4.49 (which I was using originally). the decision to move > up was because I hoped that the problem would disappear when using a > more recent version of openldap. as it turns out, it didn't :( There's no such thing as 2.4.49. I assume you mean 2.3.40? Or 2.3.39? I would use 2.3.40 over 2.3.39, and I would suggest doing your debugging with the OpenLDAP 2.4.7 release as it is unlikely there is going to be any more 2.3 releases. Using 2.4 means your fix will actually get into the next release. Also, please keep the ITS included in your replies. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 07 Feb '08

07 Feb '08

hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> --On Thursday, February 07, 2008 6:56 PM -0500 Oren Laadan >> <orenl(a)cs.columbia.edu> wrote: >> >>> More threads, less threads -- it still happens :( >>> >>> Attached is the last part of the log before it stopped responding >>> (you can see towards the end the time gap). >>> >>> Also attached is the backtrace of all threads (thanks to gdb). >> Your backtrace is fairly useless. You need to do a make install STRIP="" >> so it doesn't strip the binaries on installation. Or copy over the slapd >> from your build area, as that is pre-stripping. Additionally, I'd add the >> patch from ITS#5341 to your build. >> >> Reading symbols from /usr/local/opt/ldap-2.4.7/libexec/slapd...(no >> debugging symbols found)...done. > > It shows enough; back-meta is hanging waiting for responses from some other > LDAP server. This is a pretty bad configuration; you should not use back-meta > (or back-ldap) to redirect queries back into the same slapd. You should use > back-relay instead. I'm not quite sure why having the server query itself is such a bad idea. Can you please explain ? Let me repeat how my setup works: * there exists an LDAP server "ldap.cs.example.com" for domain CS.EXAMPLE.COM * I need to build a server that extends the contents of that server, for the same domain; but I don't have access to the DB of that server. * My clients will use my server, with the domain CS.EXAMPLE.COM (instead of querying the original server) * So I set up my own LDAP server "ldap.MINE.CS.EXAMPLE.COM" that serves two databases: (1) a BDB-backend for domain MINE.CS.EXAMPLE.COM that holds a very small database (less than 100 entries). (2) a META-backend for domain CS.EXAMPLE.COM that is configured to relay to both the original server (ldap.cs.example.com) and also relay to the local (other) server (ldap.mine.cs.example.com); the second relay is done with "suffixmassage" to convert from CS.EXAMPLE.COM to MINE.CS.EXAMPLE.COM and back. So, yes, my server/2nd-DB effectively relays queries to the my server/1st-DB The questions are: (1) why is this such a bad idea ? (2) how would I use back-ldap in place ? Note that the reason to originally select the meta-ldap backend was because it was the only one that I could find in the docs that automagically merges two separate databases and presents them as a single database the client. Thanks. Oren.

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 07 Feb '08

07 Feb '08

quanah(a)zimbra.com wrote: > --On Thursday, February 07, 2008 6:56 PM -0500 Oren Laadan > <orenl(a)cs.columbia.edu> wrote: > >> More threads, less threads -- it still happens :( >> >> Attached is the last part of the log before it stopped responding >> (you can see towards the end the time gap). >> >> Also attached is the backtrace of all threads (thanks to gdb). > > Your backtrace is fairly useless. You need to do a make install STRIP="" > so it doesn't strip the binaries on installation. Or copy over the slapd > from your build area, as that is pre-stripping. Additionally, I'd add the > patch from ITS#5341 to your build. > > Reading symbols from /usr/local/opt/ldap-2.4.7/libexec/slapd...(no > debugging symbols found)...done. It shows enough; back-meta is hanging waiting for responses from some other LDAP server. This is a pretty bad configuration; you should not use back-meta (or back-ldap) to redirect queries back into the same slapd. You should use back-relay instead. -- -- 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

← Newer
1
...
12
13
14
15
16
17
18
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008