openldap-bugs April 2008

openldap-bugs@openldap.org

45 participants
192 discussions

Re: (ITS#4890) Default Values overlay (patch)
by docelic＠spinlocksolutions.com 11 Apr '08

11 Apr '08

The contrib section does not have usable makefiles (nor the system to create them). Putting this overlay in contrib, where it would be unmaintained and practically broken right away from the start (due to missing build integration) doesn't make any sense. People interested in the overlay are able to download it from the maintained location at: http://techpubs.spinlocksolutions.com/openldap/ Davor Ocelic Spinlock Solutions http://www.spinlocksolutions.com/

1 0

Re: (ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

On Fri, Apr 11, 2008 at 11:34:33AM +0200, Rein Tollevik wrote: > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. OK, we switched to the CVS version (openldap-20080411). The patch is rejected, as You might guess :-) The problem persists more or less, anyway. FYI: Whenever the replication stops, in the provider-log (sync, conns) there is a line: Apr 11 15:30:12 1 slapd[8994]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" I don't know if this is really meaningful. Just for those people not too familiar with CVS: How can I retrieve that very branch, where the hunk in ITS 5454 would succeed? Thank You very much in advance, anyway, and the help in the past! -- Mit freundlichen Gruessen / Yours sincerely Marian Eichholz Postmaster

1 0

Re: (ITS#5463) syncrepl stops or pauses
by hyc＠symas.com 11 Apr '08

11 Apr '08

rein(a)basefarm.no wrote: > marian.eichholz(a)freenet.ag skrev: >> Full_Name: >> Version: 2.4.8 >> OS: Linux 2.6.23.13 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.97.7.65) >> >> The replication may suddenly stop, and we see no reason for that. Sometimes it >> recovers by itself, sometimes it recovers only when the consumer slapd is >> stopped and restarted. >> Is there a "golden path" to debug this issue? > > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. > > An alternative version is implemented in the CVS head release, but that > lacks a change from trylock to real mutex lock before the race condition > is fully closed. > > We experienced a lot of replication problems after upgrading from a > slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are > currently using the CVS head version (as it was about a week ago), and > most of our problems has been solved there :-) You should consider the > cvs version, as it has many syncrepl and syncprov fixes. At this point it would be better to test RE24, not HEAD. -- -- 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

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> OK, reverted the trylock (which was put there in rev 1.376). I >> unfortunately don't remember what prompted that commit; certainly >> there was no ITS associated with it. > > It was committed 9 minutes before this message: > http://www.openldap.org/lists/openldap-devel/200802/msg00032.html > Thanks for that reference. test050 is fine right now; I think rev 1.381 was the more correct fix for that problem. -- -- 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

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by h.b.furuseth＠usit.uio.no 11 Apr '08

11 Apr '08

hyc(a)symas.com writes: > OK, reverted the trylock (which was put there in rev 1.376). I > unfortunately don't remember what prompted that commit; certainly > there was no ITS associated with it. It was committed 9 minutes before this message: http://www.openldap.org/lists/openldap-devel/200802/msg00032.html -- Hallvard

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

hyc(a)symas.com wrote: >>> It also occurs to me that we probably don't even need to manipulate the >>> slapd runqueue in persist mode, when si->si_conn is already set. I.e., >>> in that case we can only have gotten here because of a listener event, >>> and not because of a runqueue schedule. >> That is probably true. > > Right, my patch avoids that now. Having looked at it again I think replacing > the trylock with a regular lock is fine. OK, reverted the trylock (which was put there in rev 1.376). I unfortunately don't remember what prompted that commit; certainly there was no ITS associated with it. -- -- 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

Re: (ITS#5463) syncrepl stops or pauses
by rein＠basefarm.no 11 Apr '08

11 Apr '08

marian.eichholz(a)freenet.ag skrev: > Full_Name: > Version: 2.4.8 > OS: Linux 2.6.23.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > The replication may suddenly stop, and we see no reason for that. Sometimes it > recovers by itself, sometimes it recovers only when the consumer slapd is > stopped and restarted. > Is there a "golden path" to debug this issue? This sounds a lot like the problems we had, see ITS#5454. Replication has been running smootly since we implemented the patch included there. An alternative version is implemented in the CVS head release, but that lacks a change from trylock to real mutex lock before the race condition is fully closed. We experienced a lot of replication problems after upgrading from a slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are currently using the CVS head version (as it was about a week ago), and most of our problems has been solved there :-) You should consider the cvs version, as it has many syncrepl and syncprov fixes. -- Rein Tollevik Basefarm AS

1 0

(ITS#5464) ucred guarded by __USE_GNU in glibc 2.8
by rhafer＠suse.de 11 Apr '08

11 Apr '08

Full_Name: Ralf Haferkamp Version: Any OS: Linux (glibc 2.8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.17) Newer glibc Version guards the definition of struct ucred (e.g. used in liblutil/getpeereid.c) by __USE_GNU, hence it is only available when _GNU_SOURCE is defined. The matching glibc changelog only say "Cleanup namespace.". Here's the diff: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/…

1 0

(ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

Full_Name: Version: 2.4.8 OS: Linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Were still migrating von slurpd to syncrepl. We have a 2.3-slurpd-fed provider under OpenLDAP 2.4.8 used by currently two OpenLDAP 2.4.8 consumers with "refreshAndPersist" and a retry-interval of "180 +" (see below) The database is fairly large (8 Mio objects, 15 GB BDB files) and the consumers have a syncrepled database (pulled once, then cloned). There are ongoing updates "each second". We see two issues: When a consumer (re-) connects, the replication for the running consumer pauses until it continues on both nodes. This could become a problem, where a single consumer can be a SPOF for the whole cluster. The replication may suddenly stop, and we see no reason for that. Sometimes it recovers by itself, sometimes it recovers only when the consumer slapd is stopped and restarted. Is there a "golden path" to debug this issue? For the logs: We have "sync" as log level. Consumer 1 (rid 000) [...] Apr 10 16:15:18 0 slapd[27548]: connection_input: conn=192 deferring operation: binding [...] Apr 11 08:45:21 0 slapd[27548]: connection_input: conn=5182 deferring operation: binding Apr 11 08:50:11 0 slapd[27548]: connection_input: conn=5207 deferring operation: binding Apr 11 08:51:09 0 slapd[27548]: connection_input: conn=5212 deferring operation: binding Apr 11 08:53:05 0 slapd[27548]: connection_input: conn=5222 deferring operation: binding Apr 11 08:54:03 0 slapd[27548]: connection_input: conn=5228 deferring operation: binding Consumer 2 (rid 002): [...] Apr 11 02:00:16 2 slapd[22272]: connection_input: conn=3151 deferring operation: binding [...] Apr 11 08:52:09 2 slapd[22272]: connection_input: conn=5224 deferring operation: binding Apr 11 08:53:07 2 slapd[22272]: connection_input: conn=5229 deferring operation: binding Provider (filtered for last syncprov_sendresp entries per rid) Apr 10 16:06:43 1 slapd[27917]: syncprov_sendresp: cookie=rid=000,csn=2008041014 0643.069039Z#000000#000#000000 Apr 11 01:57:58 1 slapd[27917]: syncprov_sendresp: cookie=rid=002,csn=2008041023 5758.696324Z#000000#000#000000 I see no indicators for failing operations, missing resources or any other trouble, incept for the "connection_input" entries. Any idea how to get sync replication running smoothly and reliably? Thank You very much in advance, of course! OK, here are configuraiton snippets for provider and consumer, if it helps. To be honest: I am not quite shure about a reasonable size for syncprov-sessionlog, even after reading the slapo-syncprov. The actual number is meant as "big, but finite". Consumer: --------- syncrepl rid=2 provider="ldap://provider:389" type=refreshAndPersist bindmethod=simple binddn=... credentials=... searchbase=... retry="180 +" provider: --------- database bdb dbnosync cachesize 200000 suffix ... rootdn ... updatedn ... rootpw ... directory /var/ldap/db lastmod on index objectClass eq ... index entryCSN,entryUUID eq checkpoint 512 15 overlay syncprov syncprov-sessionlog 300000 database monitor

1 0

(ITS#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 10 Apr '08

10 Apr '08

Full_Name: Peter O'Gorman Version: 2.4.8 OS: multiple URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch Submission from: (NULL) (24.76.165.223) gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows the conf file option to work when building openldap with gnutls on systems that do not have a /dev/random.

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
20
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 April 2008