openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

(ITS#6336) filedescriptor leak libnspr4.so
by liedekef＠telenet.be 18 Oct '09

18 Oct '09

Full_Name: Franky Van Liedekerke Version: openldap-servers-2.4.15-6.fc11.i586 OS: Fedora 11 URL: Submission from: (NULL) (84.197.109.39) I'm running openldap version 2.4.15-6 (rpm) on a up-to-date fedora 11 server. After some time, my openldap stops responding, and I narrowed it down to a file descriptor leak, where openldap keeps /lib/libnspr4.so open X times untill it runs out of file descriptors. It seems to be related to this redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=502133 Below is a small strace of 1 openldap thread where it is clearly shown that a thread opens up libnspr4.so but never closes it again. Unfortunately, I can't reproduce this with any ldap query, so it seems to be related to the thread lib itself ... [pid 24483] <... futex resumed> ) = 0 [pid 24483] futex(0xffb6cc, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 68, MSG_NOSIGNAL) = 68 [pid 24483] time(NULL) = 1255876596 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 83, MSG_NOSIGNAL) = 83 [pid 24483] read(13, "09\2\2\0\220`3"..., 8) = 8 [pid 24483] read(13, "\2\1\3\4\"cn=Sandra Gyles,ou=users,o=g"..., 51) = 51 [pid 24483] time(NULL) = 1255876596 [pid 24483] read(13, 0x1088213, 8) = -1 EAGAIN (Resource temporarily unavailable) [pid 24483] epoll_ctl(6, EPOLL_CTL_MOD, 13, {EPOLLIN, {u32=16643796, u64=16643796}}) = 0 [pid 24483] write(5, "0"..., 1) = 1 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 57, MSG_NOSIGNAL) = 57 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 92, MSG_NOSIGNAL) = 92 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 130, MSG_NOSIGNAL) = 130 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 105, MSG_NOSIGNAL) = 105 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 86, MSG_NOSIGNAL) = 86 [pid 24483] open("/etc/ld.so.cache", O_RDONLY) = 38 [pid 24483] fstat64(38, {st_mode=S_IFREG|0644, st_size=57720, ...}) = 0 [pid 24483] mmap2(NULL, 57720, PROT_READ, MAP_PRIVATE, 38, 0) = 0xa12ec000 [pid 24483] close(38) = 0 [pid 24483] open("/lib/libnspr4.so", O_RDONLY) = 38 [pid 24483] read(38, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\10`\0054\0\0\0\214"..., 512) = 512 [pid 24483] fstat64(38, {st_mode=S_IFREG|0755, st_size=232252, ...}) = 0 [pid 24483] munmap(0xa12ec000, 57720) = 0 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 130, MSG_NOSIGNAL) = 130 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 71, MSG_NOSIGNAL) = 71 [pid 24483] time(NULL) = 1255876596 [pid 24483] send(3, "<167>Oct 18 16:36:36 slapd[23759]"..., 78, MSG_NOSIGNAL) = 78 [pid 24483] write(13, "0\r\2\2\0\220a\7\n\1\0\4\0\4\0"..., 15) = 15 [pid 24483] futex(0xffb6e8, FUTEX_WAIT_PRIVATE, 434, NULL <unfinished ...>

1 0

Re: (ITS#6334) hang during ldapmodify
by masarati＠aero.polimi.it 17 Oct '09

17 Oct '09

> Matthew and Hallvard, > > Matthew Backes wrote: >> Large collections of values can be slow for some uses; have you looked >> at the sortvals option? (needs a db reload with slapcat+slapadd) > > Thanks for your suggestion to add the sortvals option. I've done so and > still experience the hangs. > >>> memberUid: t2479 >> >> That doesn't seem terribly large, no. sortvals is more pertinent if you >> have 100k+ values on the attribute... > > Exactly what I was thinking. This doesn't seem like a really large > number, but it's consistently hanging for us. A consistent hang calls for some deadlock. Your configuration might be tweaking some strange interoperation of functionalities that result in the deadlock. So, rather than the logs, the configuration would be of paramount interest. We are obviously looking for details, so don't omit anything; rather sanitize sensitive information, like passwords. I'm specifically thinking about some strange interoperation between databases, overlays, ACLs and so. p.

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 16 Oct '09

16 Oct '09

The ones BEFORE that spanned a few days. How about the fact that I had to open ANOTHER ticket to someone's attention to get THIS ONE "figured out"? THIS was what irritated me. And from the looks of things, I was wrong: 6320 is the result of Unreliable Synchronization, the deadlocking issue made it worse, but is a separate issue. So you still have a ticket (6320) that was unresolved. Yes, I said don't bother -- but how about the few posts before that, with me asking for more help and getting no responses? I had to make an ASSUMPTION, based on Pierangelo's suggestion. Given what he said, and given what I'd observed, it seemed a valid assumption, but was not. The problem is that OpenLDAP has SO MANY PROBLEMS, its almost impossible to discern ONE from ANOTHER unless you WORK at the OpenLDAP foundation. Thats unreasonable and I don't have time for two jobs. Anyways, Quanah, I think we should just drop this now, as its going to get into a screaming match regarding the following issues: * Unreliable OpenLDAP releases * Lackluster/falsely-advertised SyncRepl behavior * Lengthy-delays in helpful ticket responses * Paid-version does not mitigate "free" version issues * My frustration with OpenLDAP as a whole I don't want to be Master Yoda's age by the time this stuff is resolved. And I don't want to spend the rest of this year debating it with you. So please, just drop it.

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 8:56 PM +0000 j(a)telepaths.org wrote: > Overall declining bugs, yes. > > Bugs I HAVE personally observed since 2.3 -> 2.4 = INCREASING. > > We currently use OpenLDAP 2.3x with Delta SyncRepl (single master) > with no issues. > > If I take that same setup into OL 2.4x, the problems get VERY BAD: > > * Data stops being replicated RANDOMLY > * Writes stop 'getting honored' > * Binary crashes > * Man pages make me want to light myself on fire. > > I realize this software is free. Obviously. > > I realize this software is supported by volunteers. But my old > ticket, 6320, is getting no more attention from anyone. I need > something better than that. I have a PROBLEM. And people STOPPED > RESPONDING TO ME. This is --> unacceptable <-- The last email you sent to ITS#6320 was: Followup 25 Download message Subject: Re: (ITS#6320) From: Jeff Doyle <j(a)telepaths.org> Date: Wed, 14 Oct 2009 18:27:31 -0700 To: openldap-its(a)OpenLDAP.org OK, for anyone following this thread, please refer to ITS #6331, as I believe this issue may not be a "replication issue" at all, rather a deadlock PREVENTING replication. Might as well close this ticket, thanks for everyone's help. Jeff Why would you expect anyone to respond? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 16 Oct '09

16 Oct '09

Matthew and Hallvard, Matthew Backes wrote: > Large collections of values can be slow for some uses; have you looked > at the sortvals option? (needs a db reload with slapcat+slapadd) Thanks for your suggestion to add the sortvals option. I've done so and still experience the hangs. >> memberUid: t2479 > > That doesn't seem terribly large, no. sortvals is more pertinent if you > have 100k+ values on the attribute... Exactly what I was thinking. This doesn't seem like a really large number, but it's consistently hanging for us. >> The update simply hangs. Tossing a "-d 65535" shows that the process is >> sitting in loop spitting out messages similar to: > >> ldap_int_select > > This looks like you added -d to your ldapmodify. More useful here would > be server logs; try running slapd with -d 263 so we can see more of what > the server is trying. (1+2+4+256) > >> I'm happy to provide any additional details or debugging information, >> just let >> me know what you need. > > Can you attach a gdb backtrace taken during the hang? (thread apply all > backtrace full) I'll try and get these two completed over the weekend, at a minimum work on this Monday. Is there somewhere I can upload these logs to, where they won't go out to a public list? It's quite possible there might be information in here that we would prefer not go public. Thanks! Mark

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 16 Oct '09

16 Oct '09

Overall declining bugs, yes. Bugs I HAVE personally observed since 2.3 -> 2.4 = INCREASING. We currently use OpenLDAP 2.3x with Delta SyncRepl (single master) with no issues. If I take that same setup into OL 2.4x, the problems get VERY BAD: * Data stops being replicated RANDOMLY * Writes stop 'getting honored' * Binary crashes * Man pages make me want to light myself on fire. I realize this software is free. Obviously. I realize this software is supported by volunteers. But my old ticket, 6320, is getting no more attention from anyone. I need something better than that. I have a PROBLEM. And people STOPPED RESPONDING TO ME. This is --> unacceptable <-- To comment on your statement: > If what you need is immediate on demand support, then I would > advise you look into a support contract with one of the companies > that provides support for OpenLDAP. That is NOT what I need. What I need is a stable version of OpenLDAP that works reliably and as-promised. I'm sorry, but NO ONE should have mentioned Multi-Master ANYWHERE (OpenLDAP.org, man-pages, Zytrax.com ) until it was STABLE. It is NOT stable. If what you say is true, then it will be a LONG TIME before OpenLDAP does what I want, like its advertised. So thats why I am going elsewhere. Money is not the issue - we're happy to spend money on something that works. Furthermore, if MultiMaster has 'kinks' to be worked-out, and since some people condemn the use of MultiMaster, I'm not going to wait around for a better solution to be willed into existence. I'm done. My own manager shot down the idea of getting the "Paid" Version of OpenLDAP because he feels that many of the inadequacies of OpenLDAP (free-version) are simply SALES PITCHES to coerce people into buying the paid version. Given what Sun offers, what with ZFS and all, I can see why he wants to go the Sun-route, because it will be a more long- term blanket solution to afford benefits to us, both inside and outside of the Directory Services we intend to offer. And after reading Sun's documentation on Sun Directory services, I was more than slightly-interested in looking into it further. Also, Suns docs are easier to read. Given how much I have learned about openLDAP, and how much effort I've put into it, proceeding any further would be STUPID of me. I need to stop and consider other options. OpenLDAP simply cannot meet our needs. I have to accept this. And another thing: > If you think the other open source LDAP software packages or even > commercial packages are better, go use one and learn why they aren't. I respect your loyalty to the OpenLDAP project. Right now however, I can't imagine anything WORSE than what OpenLDAP is giving me. Losing a feature or two is better that inexplicable segfaults and freezes. Replication thats been released in 'Prime Time' but isn't ready for Prime Time??? ...... please. Enough is enough. Thanks again, but I give up. Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 7:38 PM +0000 j(a)telepaths.org wrote: > Program received signal SIGPIPE, Broken pipe. > [Switching to Thread 0x43662950 (LWP 11001)] > 0x00007fb10ea8275b in write () from /lib/libpthread.so.0 > > ... during my GDB debugging session. FOR NO REASON. This isn't an indication of a problem, and is quite normal to occur. Tell GDB to ignore sigpipes. As for the rest of your email, remember that OpenLDAP is provided free of charge, and the people who work on it often do so on a volunteer basis. If you think the other open source LDAP software packages or even commercial packages are better, go use one and learn why they aren't. Every initial release series of OpenLDAP, and pretty much any software I've ever used, have had problems with new features. If you find this unusual, you've led a blessed life. Multi-Master is in and of itself problematic in its concept, and I expect it will be a while before every single issue is shaken out of the woodwork. However, given the generally *declining* number of bugs filed against MMR, I'd say its quality has improved markedly. I wouldn't consider OpenLDAP 2.3 stable until around the 30 somethingish release, btw, if you were using some of the new features (like syncrepl, etc). If what you need is immediate on demand support, then I would advise you look into a support contract with one of the companies that provides support for OpenLDAP. That's what I've always done at the companies I work at that depend on their LDAP deployment. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6334) hang during ldapmodify
by mbackes＠symas.com 16 Oct '09

16 Oct '09

Hello, Mark. > Up until recently, this had been working great. We are now > experiencing > hangs whenever we try to update the records with one particular group. > I think the hangs are occur when we try to feed too much data to > ldapmodify at a time. For instance, if I have the above group and try > to apply the following ldif file: Large collections of values can be slow for some uses; have you looked at the sortvals option? (needs a db reload with slapcat+slapadd) > memberUid: t2479 That doesn't seem terribly large, no. sortvals is more pertinent if you have 100k+ values on the attribute... > The update simply hangs. Tossing a "-d 65535" shows that the > process is > sitting in loop spitting out messages similar to: > ldap_int_select This looks like you added -d to your ldapmodify. More useful here would be server logs; try running slapd with -d 263 so we can see more of what the server is trying. (1+2+4+256) > I'm happy to provide any additional details or debugging > information, just let > me know what you need. Can you attach a gdb backtrace taken during the hang? (thread apply all backtrace full) Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 16 Oct '09

16 Oct '09

Quanah, Here is the output of db_stat -c: 114 Last allocated locker ID. 2147M Current maximum unused locker ID. 9 Number of lock modes. 10000 Maximum number of locks possible. 10000 Maximum number of lockers possible. 10000 Maximum number of lock objects possible. 18 Number of current locks. 107 Maximum number of locks at any one time. 112 Number of current lockers. 112 Maximum number of lockers at any one time. 18 Number of current lock objects. 64 Maximum number of lock objects at any one time. 2832673 Total number of locks requested. 2832655 Total number of locks released. 0 Total number of lock requests failing because DB_LOCK_NOWAIT was set. 5 Total number of locks not immediately available due to conflicts. 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. 3MB 624KB The size of the lock region.. 470 The number of region locks granted after waiting. 4491131 The number of region locks granted without waiting. The information looks fine to me, however, I am totally willing to admit I am not great at tuning bdb. I've spent time reading through the tuning docs and made a best effort, but it is entirely possible this could be a tuning issue. Thanks! Mark > What is the output from db_stat (For your BDB version) -c in your > database where you are making modifications? Have you run out of > locks/lockers/lock objects? > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 16 Oct '09

16 Oct '09

OK, I'm not going to waste any more of your guys' time, nor mine. I am going to abandon the use of OpenLDAP forever. I've spent the last three years learning it as well as possible and its not getting me anywhere. I own 7 books on the subject - and they're mostly crap. What one doesn't cover, the other covers in 'vague' detail. The man pages for OpenLDAP suck, mostly. And when you complain on this point, someone's response is to "write one better". Well professor, If I knew enough to WRITE my own manpage, why the hell would i be READING one??? I almost sold my soul to Satan to attend LDAPcon2009 - didn't work out, so I couldn't. My only desire to go to this event was to meet Howard Chu, anyway. I'm tired of all of this crap. In one release, MultiMaster isn't supported. In the next, it IS supported, but has SyncRepl issues in 2.4.11 - kind of a BIG PROBLEM, don't you think?? In 2.4.17, it has dead-lock issues, causing a server to lock up and no longer accept WRITES, but will continue to allow READS - I can't even fathom how or why this is considered 'acceptable'. and now, in 2.4.19, I'm getting: Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x43662950 (LWP 11001)] 0x00007fb10ea8275b in write () from /lib/libpthread.so.0 ... during my GDB debugging session. FOR NO REASON. This is in ADDITION to the SegFaults i received yesterday (the reason for which I was USING gdb in the 1st place). I'm completely done using your Software. OpenLDAP's quality has irretrievably gone down hill, and I'm sorry, but I'm tired of spending most of my career trying to build the PERFECT directory server only to find out that its not stable (but sadly, does EVERYTHING we want). OpenLDAP is no longer an industry capable suite, it is not reliable, replication is a joke (doesn't log ADD operations???), stable MultiMaster is a LIE, everything is poorly documented and it is genuinely disappointing on so many levels that I won't waste your time by stating them here. From my reading, the only way I will ever be satisfied with "LDAP" is by going with a Sun implementation, since it offers EVERYTHING we currently have & want from LDAP, except its probably got good documentation and support that I can rely on for enterprise-level needs. I've read some posts on your site, suggesting the need to 'revamp' some of slapd's code. My suggestion to you guys is GET ON IT NOW. I want to thank Pierangelo and Quanah for being the more 'active' participants in my cries for help. Please close the following tickets, since I'm never going to try any of this ever again: ITS # 6320 ITS # 6331 Forgive my loss of patience, but you'd be upset too if something you've devoted the last three years of your career was beginning to resemble "a lost cause" that requires unending attention. My job requires results, not full-time LDAP analyst. Thanks again, farewell. Jeff

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
23
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 October 2009