openldap-devel

openldap-devel@openldap.org

1418 discussions

contextCSN of subordinate syncrepl DBs
by Rein Tollevik 22 Nov '09

22 Nov '09

I've been trying to figure out why syncrepl used on a backend that is subordinate to a glue database with the syncprov overlay should save the contextCSN in the suffix of the glue database rather than the suffix of the backend where syncrepl is used. But all I come up with are reasons why this should not be the case. So, unless anyone can enlighten me as to what I'm missing, I suggest that this be changed. The problem with the current design is that it makes it impossible to reliably replicate more than one subordinate db from the same remote server, as there are now race conditions where one of the subordinate backends could save an updated contextCSN value that is picked up by the other before it has finished its synchronization. An example of a configuration where more than one subordinate db replicated from the same server might be necessary is the central master described in my previous posting in http://www.openldap.org/lists/openldap-devel/200806/msg00041.html My idea as to how this race condition could be verified was to add enough entries to one of the backends (while the consumer was stopped) to make it possible to restart the consumer after the first backend had saved the updated contextCSN but before the second has finished its synchronization. But I was able to produce it by simply add or delete of an entry in one of the backends before starting the consumer. Far to often was the backend without any changes able to pick up and save the updated contextCSN from the producer before syncrepl on the second backend fetched its initial value. I.e it started with an updated contextCSN and didn't receive the changes that had taken place on the producer. If syncrepl stored the values in the suffix of their own database then they wouldn't interfere with each other like this. There is a similar problem in syncprov, as it must use the lowest contextCSN value (with a given sid) saved by the syncrepl backends configured within the subtree where syncprov is used. But to do that it also needs to distinguish the contextCSN values of each syncrepl backend, which it can't do when they all save them in the glue suffix. This also implies that syncprov must ignore contextCSN updates from syncrepl until all syncrepl backends has saved a value, and that syncprov on the provider must send newCookie sync info messages when it updates its contextCSN value when the changed entry isn't being replicated to a consumer. I.e as outlined in the message referred to above. Neither of these changes should interfere with ordinary multi-master configurations where syncrepl and syncprov are both use on the same (glue) database. I'll volunteer to implement and test the necessary changes if this is the right solution. But to know whether my analysis is correct or not I need feedback. So, comments please? -- Rein Tollevik Basefarm AS

2 6

Re: commit: ldap/doc/man/man5 slapd.conf.5
by Quanah Gibson-Mount 22 Nov '09

22 Nov '09

--On Sunday, November 22, 2009 1:44 PM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5 > > Modified Files: > slapd.conf.5 1.310 -> 1.311 > > Log Message: > minimal documentation of authid-rewrite* stuff > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/ > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/slapd.conf.5 > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. Shouldn't there be a corresponding update do slapd-config(5)? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: commit: ldap/servers/slapd config.c
by Hallvard B Furuseth 22 Nov '09

22 Nov '09

ando(a)OpenLDAP.org writes: > config.c 1.506 -> 1.507 > silence signedness warnings > > - } else if ( rc == ARG_BAD_CONF ) { > + } else if ( (unsigned long)rc == ARG_BAD_CONF ) { That breaks working code. Never shut up signedness warnings without working through what the expressions do, it's too easy to go wrong. rc is an int. ARG_BAD_CONF = 0xdead0000: an unsigned int if int is 32-bit. Consider 32-bit int, 64-bit long, with rc == (int)ARG_BAD_CONF: rc < 0 so (unsigned long)rc sign-extends to 0xffffffffdead0000, but ARG_BAD_CONF itself is positive so it is not sign-extended. The old code worked as far as I can tell: It converted rc to unsigned int, yielding the original ARG_BAD_CONF. The same functinality change happens with the other changes below that one, I haven't looked at whether that is a fix of broken code or if it breaks working code. (Or it is breaks broken code in a new way:-) -- Hallvard

2 2

Re: commit: ldap/servers/slapd backend.c
by Hallvard B Furuseth 21 Nov '09

21 Nov '09

hyc(a)OpenLDAP.org writes: > backend.c 1.412 -> 1.413 > ITS#6393 syncrepl internal connids are now <= -1000 backend.c: 'op->o_connid <= -1000' is wrong. o_connid is unsigned long, so this is compiled as 'op->o_connid <= (unsigned long) -1000'. I haven't looked at possible connid values, but maybe you want o_connid >= (unsigned long)-1000. -- Hallvard

3 5

Re: commit: ldap/servers/slapd backend.c
by masarati＠aero.polimi.it 21 Nov '09

21 Nov '09

> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > backend.c 1.412 -> 1.413 > > Log Message: > ITS#6393 syncrepl internal connids are now <= -1000 What about checking this through a macro? #define SLAPD_SYNC_CONN_OFFSET (-1000) #define SLAPD_SYNC_CONN(connid) ((connid) <= SLAPD_SYNC_CONN_OFFSET) p.

2 1

Re: RE24 (2.4.20) testing call #3
by Gavin Henry 20 Nov '09

20 Nov '09

----- "Dieter Kluenter" <dieter(a)dkluenter.de> wrote: > Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > > > A few new changes, please re-sync and test. Thanks! Hopefully > this > > will be the last of it. In particular, watch test050 please. ;) > > Success, x86_64, openSUSE-11.1 +1 for i386 Fedora 11. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

forcing valgrind dumps
by Hallvard B Furuseth 19 Nov '09

19 Nov '09

Here is a patch to force valgrind to dump memory leaks or all allocations while running. Next we need a patch to filter old allocations out from new one, leaving recent allocations. Dunno if it belongs in the source code or not... IIRC we do have #ifdefs for some external malloc debug stuff already, but I didn't find that now:-( Index: servers/slapd/daemon.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/daemon.c,v retrieving revision 1.442 diff -u -2 -r1.442 daemon.c --- servers/slapd/daemon.c 13 Nov 2009 22:48:51 -0000 1.442 +++ servers/slapd/daemon.c 18 Nov 2009 23:18:29 -0000 @@ -36,4 +36,22 @@ #include <ac/unistd.h> +#ifdef USE_VALGRIND +/* + * When running under valgrind, make kill -USR1 force a leak/alloc dump + * to stderr, in addition to its usual "wake listener" function. + * After SIGUSR1 there will also be a dump before shutdown. + * + * Usage: + * valgrind --leak-check=yes --show-reachable=yes slapd -d0 2>slapd.out & + * kill -USR1 <slapd or valgrind process> + * + * For recent leaks/allocs only, do kill -USR1 after startup and again + * sometime later. Then filter out from the 2nd dump the occurrences of + * allocs from the 1st dump. + */ +#include <ac/signal.h> +#include <valgrind/memcheck.h> +#endif /* USE_VALGRIND */ + #include "slap.h" #include "ldap_pvt_thread.h" @@ -664,4 +682,25 @@ #endif /* ! epoll && ! /dev/poll */ +#ifdef USE_VALGRIND +static sig_atomic_t slap_valgrind_requested = 0; +#define slap_valgrind_request() ((void) (slap_valgrind_requested = 2)) +static void +slap_valgrind_check( int when, const char *msg ) +{ + if ( slap_valgrind_requested >= when && RUNNING_ON_VALGRIND ) { + Debug( LDAP_DEBUG_TRACE, "Valgrind dump %s\n", msg, 0, 0 ); + /* Needed for terminator between valgrind -q dumps */ + VALGRIND_PRINTF( "==> Valgrind dump %s\n", msg ); + VALGRIND_DO_LEAK_CHECK; + VALGRIND_PRINTF( "<== Valgrind dump %s\n", msg ); + slap_valgrind_requested = 1; + } +} + +#else /* !USE_VALGRIND */ +#define slap_valgrind_check(when, msg) ((void) 0) +#define slap_valgrind_request() ((void) 0) +#endif /* USE_VALGRIND */ + #ifdef HAVE_SLP /* @@ -2308,4 +2347,6 @@ struct re_s* rtask; + slap_valgrind_check( 2, "while running" ); + now = slap_get_time(); @@ -2760,4 +2801,6 @@ } + slap_valgrind_check( 1, "before shutdown" ); + if ( slapd_gentle_shutdown != 2 ) close_listeners ( 0 ); @@ -2942,4 +2985,6 @@ int save_errno = errno; + slap_valgrind_request(); + WAKE_LISTENER(1);

2 2

Re: commit: ldap/servers/slapd connection.c slap.h
by Hallvard B Furuseth 19 Nov '09

19 Nov '09

hyc(a)OpenLDAP.org writes: > slap.h 1.881 -> 1.882 > >- int c_struct_state; /* structure management state */ >- int c_conn_state; /* connection state */ >+ enum sc_struct_state c_struct_state; /* structure management state */ >+ enum sc_conn_state c_conn_state; /* connection state */ Note that this is potentially a binary incompatible change. I'm never clear on how hard we try to avoid those in slapd... These enum types need not take more than 1 byte each. (OTOH enum constants declared _in_ the enum have type int.) -- Hallvard

2 1

RE24 (2.4.20) testing call #2
by Quanah Gibson-Mount 19 Nov '09

19 Nov '09

Please test current RE24 CVS. Several issues identified in the first round have been resolved. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 4

Please test RE24 for 5.0.20 candidate
by Quanah Gibson-Mount 19 Nov '09

19 Nov '09

Please test current RE24, thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel