openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.61.118) > > > Stopping central master and site2 servers to test start with emtpy db... > Starting site2 master slapd on TCP/IP port 9013... > Using ldapsearch to check that site2 master slapd is running... > Starting site2 search slapd on TCP/IP port 9016... > Using ldapsearch to check that site2 search slapd is running... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Using ldapsearch to check that site2 master received base... > Using ldapsearch to check that site2 search received base... > Waiting 1 seconds for syncrepl to receive changes... > Checking contextCSN after site2 servers repopulated... > Found 3 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed for bdb (exit 3) > make[2]: *** [bdb-mod] Error 3 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > I'm seeing the same problem here. Still haven't identified the cause, looking... -- -- 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#6378) Slapadd core dump
by michael＠stroeder.com 14 Nov '09

14 Nov '09

acirulli(a)gmail.com wrote: > Full_Name: Andrea Cirulli > Version: 2.4.16 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.77.56.182) > > > Problem with slapadd 2.4.16 using an ldif provided by slapcat 2.3.39 > > SLAPADD goes always in core dump on entry of ldif such the following: > > registeredAddress:: MTEzLjIxMS4yMjUuMTgxIAA= > > The base 64 value once converted is "113.211.225.181" + " " + '\0' Not sure whether slapcat 2.3.39 falsely added the NULL-byte at the end or whether it's part of your data. Could you please cross-check that with ldapsearch reading that particular entry? Nevertheless slapadd should not crash. Rather an error should be reported. But please try to reproduce the issue with a recent release (at least 2.4.19, preferrably CVS branch OPENLDAP_REL_ENG_2_4). Another option would be to provide sanitized test data to let others try to reproduce it. Ciao, Michael.

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 14 Nov '09

14 Nov '09

> Please provide stack traces for each of these assertions. In this case it > sounds like connection_closing() got called multiple times for the same > connection, after it had already been fully closed. A trace would help > confirm > that. This is a little odd: (gdb) run -d 255 Starting program: /usr/sbin/slapd -d 255 must compile with LDAP_DEBUG for debugging *** "CRASH" *** Program exited normally. (gdb) ba No stack. I have been running a script, while ldapsearch -x; do sleep 10; done, that eventually crashes slapd. But gdb provides little feedback, as noted above. >> One things to note is that, in addition to being on MIPS32, my platform >> has only 32MB of memory. I also have a swap file that is 64MB. > > In such an environment you won't have enough memory for more than 1 or 2 > server threads. Have you already configured this? I have just reconfigured slapd to use one thread and removed all indexes from the configuration. So far, I have not seen a crash. I am no using two clients to query slapd and have removed that sleep statements so that the server is continuously queried. I've been running this for about one hour and will report back if there are any negative results.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it 14 Nov '09

14 Nov '09

> Howard Chu wrote: >> Peter Mogensen wrote: >>> This is mirrormode. >>> There's no "provider" as such. However, there's one server which is >>> used >>> for application access and to minimize disk load on that server, the >>> plan was to take most backups from the other. >>> I can't see any difference between what you call "initializing" and >>> normal running state, except that the difference between server-1 and >>> server-2 is (somewhat) larger. >> >> If the problem is as Ando suggests, then it's because in the syncrepl >> Refresh >> phase it's receiving entries out-of-order from the provider. Ando is >> suggesting that the problem is caused when a child entry is replicated >> before >> its parent. Once the Refresh phase ends and it transitions to the >> Persist >> phase, all entries' parents will exist and so this particular condition >> will >> no longer occur. >> >> Of course, no one is saying for certain that this is the explanation, >> yet. > > It sounds reasonable to me :) > But unless you are not in any way allowed to - ever - make writes to > more than one server in a mirromode setup, this could (as I hear it) > potentially happen at any time. > The only reason I have to only make writes to one server is that I > currently (this will change) have an application which is dependant on > making writes and immediately reading back the entry. > > As I hear what you're saying is that any write to a server in a > mirrormode setup could invalidate a slapcat running on the other. > This would mean that you can never write to more that one server at all > and that's the only server you can slapcat while running. > That takes a lot of the "mirror" out of "mirrormode". Doesn't it? Based on my *very incomplete and possibly wrong* analysis, the problem would be automatically cured by using back-bdb. Also, fixing back-hdb *if it's broken at all* should be possible. p.

1 0

(ITS#6378) Slapadd core dump
by acirulli＠gmail.com 14 Nov '09

14 Nov '09

Full_Name: Andrea Cirulli Version: 2.4.16 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.77.56.182) Problem with slapadd 2.4.16 using an ldif provided by slapcat 2.3.39 SLAPADD goes always in core dump on entry of ldif such the following: registeredAddress:: MTEzLjIxMS4yMjUuMTgxIAA= The base 64 value once converted is "113.211.225.181" + " " + '\0' The output of the slapadd in verbose mode is: Assertion failed: p == &normalized->bv_val[normalized->bv_len], file schema_init.c, line 2225 Abort (core dumped) 

1 0

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

See testrun/ http://www.stroeder.com/temp/openldap/openldap-its-6377-testrun.tar.gz

1 0

(ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.61.118) Stopping central master and site2 servers to test start with emtpy db... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Using ldapsearch to check that site2 master received base... Using ldapsearch to check that site2 search received base... Waiting 1 seconds for syncrepl to receive changes... Checking contextCSN after site2 servers repopulated... Found 3 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed for bdb (exit 3) make[2]: *** [bdb-mod] Error 3 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 14 Nov '09

14 Nov '09

Howard Chu wrote: > Peter Mogensen wrote: >> This is mirrormode. >> There's no "provider" as such. However, there's one server which is used >> for application access and to minimize disk load on that server, the >> plan was to take most backups from the other. >> I can't see any difference between what you call "initializing" and >> normal running state, except that the difference between server-1 and >> server-2 is (somewhat) larger. > > If the problem is as Ando suggests, then it's because in the syncrepl Refresh > phase it's receiving entries out-of-order from the provider. Ando is > suggesting that the problem is caused when a child entry is replicated before > its parent. Once the Refresh phase ends and it transitions to the Persist > phase, all entries' parents will exist and so this particular condition will > no longer occur. > > Of course, no one is saying for certain that this is the explanation, yet. It sounds reasonable to me :) But unless you are not in any way allowed to - ever - make writes to more than one server in a mirromode setup, this could (as I hear it) potentially happen at any time. The only reason I have to only make writes to one server is that I currently (this will change) have an application which is dependant on making writes and immediately reading back the entry. As I hear what you're saying is that any write to a server in a mirrormode setup could invalidate a slapcat running on the other. This would mean that you can never write to more that one server at all and that's the only server you can slapcat while running. That takes a lot of the "mirror" out of "mirrormode". Doesn't it? >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? I've taking that test setup down now to test other stuff, so I can't say 100%. /Peter

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 14 Nov '09

14 Nov '09

Peter Mogensen wrote: > Howard Chu wrote: >> apm(a)mutex.dk wrote: >>> Pierangelo Masarati wrote: >>>> You appear to be using back-hdb. >>> Yes. >>> >>>> My guess is that if this can fail, e.g. because entries are being >>>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>>> get fixed anyway, though, because missing entries should exist as "glue" >>>> objects. >>> yes. But if you plan to use slapcat as a backup mechanism, then it's >>> still a problem. >> >> Sounds like a low priority issue at best. Taking backups of a replica while it >> is initializing is pointless, just take a backup of the provider instead. > > This is mirrormode. > There's no "provider" as such. However, there's one server which is used > for application access and to minimize disk load on that server, the > plan was to take most backups from the other. > I can't see any difference between what you call "initializing" and > normal running state, except that the difference between server-1 and > server-2 is (somewhat) larger. If the problem is as Ando suggests, then it's because in the syncrepl Refresh phase it's receiving entries out-of-order from the provider. Ando is suggesting that the problem is caused when a child entry is replicated before its parent. Once the Refresh phase ends and it transitions to the Persist phase, all entries' parents will exist and so this particular condition will no longer occur. Of course, no one is saying for certain that this is the explanation, yet. > If I can't trust slapcat during this > phase, how can I trust slapcat for backups? Does slapcat behave this way on the active server? -- -- 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#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Howard Chu wrote: > apm(a)mutex.dk wrote: >> Pierangelo Masarati wrote: >>> You appear to be using back-hdb. >> Yes. >> >>> My guess is that if this can fail, e.g. because entries are being >>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>> get fixed anyway, though, because missing entries should exist as "glue" >>> objects. >> yes. But if you plan to use slapcat as a backup mechanism, then it's >> still a problem. > > Sounds like a low priority issue at best. Taking backups of a replica while it > is initializing is pointless, just take a backup of the provider instead. This is mirrormode. There's no "provider" as such. However, there's one server which is used for application access and to minimize disk load on that server, the plan was to take most backups from the other. I can't see any difference between what you call "initializing" and normal running state, except that the difference between server-1 and server-2 is (somewhat) larger. If I can't trust slapcat during this phase, how can I trust slapcat for backups? /Peter

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
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 November 2009