openldap-devel

openldap-devel@openldap.org

1443 discussions

How to get rid of sys_errlist and sys_nerr?
by Michael B Allen 29 Apr '08

29 Apr '08

Hello, I'm trying to run something linked with libldap on a glibc-2.5 system on a glibc-2.3 linux system and the loader compains about not having the right versions of sys_errlist and sys_nerr. Why does libldap need these symbols? $ objdump -T libldap-2.3.so.0 | grep sys_ 0000000000000000 DO *UND* 0000000000000004 GLIBC_2.4 sys_nerr 0000000000000000 DO *UND* 0000000000000420 GLIBC_2.4 sys_errlist >From looking at config.log, configure finds strerror just fine. Is there any way to get rid of these symbols? Of all the symbols in all the libraries that make up my project these are the only two GLIBC_2.4 or above symbols. If I can get rid of them, my code should run on the glibc-2.3 system. Mike

2 4

RE24 deadlock
by Aaron Richton 29 Apr '08

29 Apr '08

https://www.nbcs.rutgers.edu/~richton/test008deadlock-RE24_20080414.txt Could just be ITS#5391 proving that it still exists. BDB 4.2.52. testrun and the process are still just sitting there (from 10 days ago, should've looked at the machine more often...)

3 7

Re: commit: ldap/servers/slapd/back-monitor cache.c
by Hallvard B Furuseth 29 Apr '08

29 Apr '08

ando(a)OpenLDAP.org writes: > Modified Files: > cache.c 1.32 -> 1.33 > avoid potential deadlock? I've never been sure of the back-monitor locking code.. Do volatile entries get cached? -- Hallvard

2 2

OpenLDAP booth at OpenExpo, 25/26 May 2008, Karlsruhe, Germany
by Michael Ströder 28 Apr '08

28 Apr '08

HI! It seems my application to run an OpenLDAP booth at http://openexpo.de/ in Germany, Karlsruhe, 25./26. May 2008 was accepted. Like requested by them I'll sent them the OpenLDAP worm logo to be put on their web page. Volunteers welcome to help at that booth. It's right before Linuxtag in Berlin, Germany. Ciao, Michael.

1 0

[Fwd: Re: deadlocks in OpenLDAP]
by Howard Chu 28 Apr '08

28 Apr '08

I haven't looked at this part of back-monitor. Someone else care to respond? -------- Original Message -------- Subject: Re: deadlocks in OpenLDAP Date: Mon, 28 Apr 2008 04:30:23 -0400 From: Yin Wang <yinw(a)umich.edu> To: Howard Chu <hyc(a)symas.com> Hi Howard, Our study shows a possible deadlock in OpenLDAP 2.4.8. Hope you could help explain. - monitor_cache_get at servers/slapd/back-monitor/cache.c:163 waiting for mp_mutex while holding mi_cache_mutex - monitor_cache_release at servers/slapd/back-monitor/cache.c:366 waiting for mi_cache_mutex while holding mp_mutex We have not been able to verify this in a real running environment, which could be difficult, if not impossible. Therefore your comments would be extremely valuable. Any help would be greatly appreciated. Yin ======= At 2008-01-12, 19:48:38 you wrote: ======= >Yin Wang wrote: >> Hi Howard, >> >> Sorry I am replying a very old email below that >> you send in last April. Terence is a colleague >> of mine and we are still working on the project. >> I hope to understand the problem better. >> >> When you said "While we can control the order of >> lock acquisition in the OpenLDAP code, we have no >> control over it in the BerkeleyDB layer", do you >> mean the (possible) deadlock comes from BerkeleyDB >> or it is because of the interaction of OpenLDAP >> and BerkeleyDB? If it is the latter case and I >> assume BerkeleyDB is deadlock-free, I don't understand >> why using such a library could cause deadlocks. >> >> Your help would be greatly appreciated. > >Since you say you're working on a research project, you shouldn't assume >anything. You should do some actual research. The BerkeleyDB lock system is >fully described in their documentation. Read it. > >If you have questions that aren't addressed by the BerkeleyDB docs you can ask >those, but I don't have time to answer questions about things that are already >well documented. >> >> Yin Wang >> Research Assistant >> EECS Department, University of Michigan >> >> >>> -----Original Message----- >>> From: Howard Chu [mailto:hyc@openldap.org] >>> Sent: Thursday, April 19, 2007 5:32 PM >>> To: Kelly, Terence P >>> Cc: Project(a)openldap.org >>> Subject: Re: deadlocks in OpenLDAP >>> >>> Kelly, Terence P wrote: >>> >>>> Hi, >>>> >>>> I'm a researcher with interests >>>> in concurrent programming issues. I'm >>>> writing with a question about deadlocks >>>> in OpenLDAP code. >>>> >>>> Based on the OpenLDAP issue tracking system, >>>> I gather that deadlocks involving circular >>>> wait for locks have occurred or have been >>>> suspected in slapd. >>>> >>>> In principle it's possible to avoid deadlock >>>> by consistently acquiring locks in a defined >>>> order, but in practice this can be inconvenient >>>> or impossible. >>>> >>>> Can you give me some intuition for why it's >>>> hard to prevent deadlocks in slapd? Has >>>> your experience with deadlocks in OpenLDAP >>>> software given you any generic insights >>>> into deadlock and how (not) to avoid it? >>>> Would your insights apply to other >>>> software in addition to slapd? >>>> >>>> Many thanks in advance for any wisdom you >>>> can share! Long editorials and brain dumps >>>> are particularly welcome. >>>> >>>> -- Terence >>> For OpenLDAP the problem is that there are two layers of locking systems >>> >>> in use - the OpenLDAP code and the BerkeleyDB code. While we can control >>> >>> the order of lock acquisition in the OpenLDAP code, we have no control >>> over it in the BerkeleyDB layer. As such, the usual approach of strictly >>> >>> ordering locks doesn't work here. > >-- > -- 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/ = = = = = = = = = = = = = = = = = = = = -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldap://ldap.openldap.org out of service
by Michael Ströder 26 Apr '08

26 Apr '08

HI! Is the demo server which was running ldap://ldap.openldap.org abandoned forever? Ciao, Michael.

1 0

LDAP transactions
by Howard Chu 24 Apr '08

24 Apr '08

Just thinking aloud right now about what's needed here. Basically all incoming requests participating in a transaction are queued until the Commit is received. Aside from basic parsing/validation, no other processing is performed until then. If an Abort is received, the queued requests are simply discarded. When the Commit request is received, all of the queued requests are performed sequentially by a single thread and the results are gathered. If any individual request fails, any preceding completed requests must be rolled back. Since I'm considering this for both back-bdb and back-ndb, it appears we're going to need some transaction-specific hooks to be added to the BackendInfo structure. 1) start a TXN, get a TXN handle 2) end a TXN: Commit or Abort For back-bdb the tricky part is exposing the updates atomically in the caches. I think the fact that entry caching uses BDB locks helps somewhat; we can keep entry cache items locked until the overall transaction completes. But for Aborts we'll either need to keep a copy of the previous cache info, or just discard it all. For now, discarding it all seems simpler. For back-ndb things are currently easy since this backend does no caching of its own. As such, once the backend issues a Commit or Abort request, there's no further (backend) work to be done. It's tempting to think about this for backglue, but we'd need a cross-database lock manager of some kind for detecting deadlocks. That implies that we really need an LDAP-level lock request, to handle distributed locking, and that the Transaction handling ought to be built on top of that. Currently the Transaction layer says nothing at all about locking, and it's up to the underying LDAP database to take care of it. I guess another approach would just be to have backglue fully serialize all transactions; if only one is outstanding at any time there can be no deadlocks. This brings up a question about whether slapd in general should fully serialize them. I was thinking, at the least, that we should only allow one active transaction per connection, though that was mainly a matter of convenience. Thoughts? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 3

delta-syncrepl, Delta-Syncrepl or Delta syncrepl?
by Gavin Henry 18 Apr '08

18 Apr '08

Hi All, How exactly is this written? Cheers.

3 2

syncrepl and schema replication crashes
by manu＠netbsd.org 17 Apr '08

17 Apr '08

I just upgraded to 2.4.8, and I experience a stability problem with synrepl and schema replication. My replicas get cn=schema,cn=config through syncrepl. If the master is restarted, the replicas tend to crash (not always, but very frequently). The problem disapear if I don't replicate cn=schema,cn=config. Below is a log of what happens at master restaty time, and the backtrace I collected in GDB. Any suggestion of what should I try next? Apr 17 22:16:01 khazad-dum slapd[6292]: conn=55 fd=13 closed (connection lost) Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrep2: rid=222 (-1) Can't contact LDAP server Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrep2: rid=022 (-1) Can't contact LDAP server Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrepl: rid=022 retrying Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrepl: rid=222 retrying Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 1] 0x08098b62 in at_next () (gdb) bt #0 0x08098b62 in at_next () #1 0x080506fe in config_generic () #2 0x0805b4e7 in config_set_vals () #3 0x0805bc9f in config_parse_add () #4 0x080579d8 in config_modify_add () #5 0x0805820e in config_modify_internal () #6 0x080585d0 in config_back_modify () #7 0x080af683 in syncrepl_entry () #8 0x080abd18 in do_syncrep2 () #9 0x080acf32 in do_syncrepl () #10 0x08063c25 in connection_read_thread () #11 0xbdbbbd61 in ldap_int_thread_pool_wrapper () from /usr/pkg/lib/libldap_r-2.4.so.2 #12 0xbd95a17d in pthread_create () from /usr/lib/libpthread.so.0 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 1

Creating entries on the fly, destroying them when operation is over
by Davor Ocelic 17 Apr '08

17 Apr '08

Hey folks, In the search callback, I need to check whether an entry exists, and if not, create it based on an another entry used as template (duplicating also eventual tree elements below it, if they exist). For example, if cn=a,cn=TESTVAL1,ou=group,dc,dc doesn't exist, it should be created from cn=a,cn=TEMPLATE,ou=group,dc,dc. The created entry (and the eventual subtree) should not persist and should be dropped after the operation finishes. Questions: 1) What's an elegant way to duplicate an entry in this way where an exact copy should be made, just with a different DN? 2) Since the entry creation is done in search callback, it can't be just "slipped in" like it would be possible in response callback alone, so how do I mark the created entry for removal when the operation is done? Can this be scheduled automatically with entry flags (like REP_ENTRY_MUSTBEFREED), or there would have to be a manual mechanism for deleting entries in response callback? Thanks, -doc

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel