openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

Re: (ITS#6320)
by j＠telepaths.org 10 Oct '09

10 Oct '09

FYI .... Before going to sleep last night, I left a persistent connection open to an LDAP server: SyncInfo Received SyncInfo Received SyncInfo Received SyncInfo Received ldap_result: Can't contact LDAP server (-1) <-- sometime during the night, the connection breaks.

1 0

Re: (ITS#6320)
by j＠telepaths.org 09 Oct '09

09 Oct '09

OK, since my last correspondence, things seemed to be going OK. All changes had been replicated perfectly until last night, I deleted one record, and it only deleted on 4 of 6 of my servers. I removed it manually from one of the other two 'offending' servers. The last one then deleted the record on its own. So it seems as though SyncRepl is highly flaky. I looked into the firewall timeout issue and determined that it is not the cause (if it were, this issue would be happening every 30 minutes (default firewall timeout for the LDAP service)). We're still using the accesslog DB for write-transactions. Jeff

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 08 Oct '09

08 Oct '09

A syncrepl-related error also happened in test050. I also can not reproduce easily. test failed - server 1 and server 4 configs differ >>>>> ./scripts/test050-syncrepl-multimaster failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 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#6310) Slapd with pcache crashes under load
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

> masarati(a)aero.polimi.it wrote: >> I didn't make any progress in debugging your issue, as I can't reproduce >> your issue using your configuration. What you see, namely some >> cacheability/answerability messages without a request could be related >> to >> pcache intercepting some internal operation, e.g. related to ACL >> checking? >> This could be intended or a mistake, but I can't tell so far. >> >> As a side note, your configuration seems to be triggering some issues in >> back-ldap. In detail, you set a rootdn, which is probably needed by >> slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm >> investigating this a little bit further, although it might not be >> related >> to your issue. >> >> p. > Yes, I have set up rootdn because pcache overlay wanted it. I will set > also some rootpw to see if this makes difference. mmmh, sounds like a red herring, sorry for the noise. p.

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by karavelov＠spnet.net 07 Oct '09

07 Oct '09

masarati(a)aero.polimi.it wrote: > I didn't make any progress in debugging your issue, as I can't reproduce > your issue using your configuration. What you see, namely some > cacheability/answerability messages without a request could be related to > pcache intercepting some internal operation, e.g. related to ACL checking? > This could be intended or a mistake, but I can't tell so far. > > As a side note, your configuration seems to be triggering some issues in > back-ldap. In detail, you set a rootdn, which is probably needed by > slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm > investigating this a little bit further, although it might not be related > to your issue. > > p. Yes, I have set up rootdn because pcache overlay wanted it. I will set also some rootpw to see if this makes difference. Luben

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

I didn't make any progress in debugging your issue, as I can't reproduce your issue using your configuration. What you see, namely some cacheability/answerability messages without a request could be related to pcache intercepting some internal operation, e.g. related to ACL checking? This could be intended or a mistake, but I can't tell so far. As a side note, your configuration seems to be triggering some issues in back-ldap. In detail, you set a rootdn, which is probably needed by slapo-pcache, but no rootpw. This is sort of confusing back-ldap. I'm investigating this a little bit further, although it might not be related to your issue. p.

1 0

(ITS#6326) back-ldap may leak when building entry with undef objectClass
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.251) Submitted by: ando The name of the undef objectClass is copied, but never used, and the pointer is lost. A fix is coming... p.

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by jwm＠horde.net 07 Oct '09

07 Oct '09

On Wed, Oct 07, 2009 at 08:02:53PM +0200, masarati(a)aero.polimi.it wrote: > Should be fixed now. Thanks. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6324) slapd -d ? emits incorrect value for LDAP_DEBUG_ANY on x86_64
by masarati＠aero.polimi.it 07 Oct '09

07 Oct '09

>> Please check the fix in HEAD. I can't check right now on x86_64, but >> I'll >> probably do it tomorrow. Apparently, I didn't break anything on 32 bit. > > 'slapd -d ?' still lists the 64-bit value for LDAP_DEBUG_ANY on x86_64: > > -- > Installed log subsystems: > > Any (18446744073709551615) > [...] > -- > > As I mentioned, this is due to the unsigned long format specifier (%lu) in > loglevel_print(). Changing the format specifier to %u emits the correct > value (4294967295) on this architecture. > > With your fix, slapd accepts the numeric value 4294967295 for > LDAP_DEBUG_ANY on x86_64. Should be fixed now. Also, please note the slightly changed behavior: the decimal *and* the hexadecimal value are both printed. This can be reversed if anyone fears it breaks anything. Thanks, p.

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by karavelov＠spnet.net 07 Oct '09

07 Oct '09

masarati(a)aero.polimi.it wrote: > No. Some overlay along the lines apparently mucks with e_private in the > entry that back-ldap is sending. It's probably slapo-pcache. I need to > debug this. You say it happens seldom. Can you recognize anything > special in the operation that triggers the assertion failure? I mean: > either in terms of special data, or in terms of special state of the > cache? This could help narrow down some means to reproduce the issue. > > Thanks, p. I have enabled full debugging info in the logs. So here are the last 1000 lines from the last abort: http://purgatory.spnet.net/~karavelov/abort/slapd.log.9004 I looked closely the generated core. Here is the gdb session: http://purgatory.spnet.net/~karavelov/abort/gdb.9004 Tell me if I could check some other variables that could help you identify the problem. Luben

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
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