openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

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

02 Oct '09

OK, maybe I wasn't clear enough, so I'll rephrase my initial question: Is it normal for a 'slapd' server to ONLY correct itself via a restart of the 'slapd' process? I asked because of my earlier findings today. Since waiting for the system to correct the discrepancy in the DIT by itself proved to be a futile exercise, and since a manual restart produced the results, it seemed as though I was observing suboptimal behavior, and was asking if this was indicative of something else. On Oct 2, 2009, at 23:02 , Howard Chu wrote: > j(a)telepaths.org wrote: >> IMPORTANT UPDATE: >> >> Is it normal for a 'slapd' server to correct itself via a restart of >> the slapd process? Currently, I have one Consumer that is 2-records >> behind in Synchronization - I restarted his process and the records >> immediately were replicated. This normally is NOT standard behavior. >> >> Can anyone explain? Is this expected? Indicative of another problem? > > That's what the "refresh" in "refreshAndPersist" is about. Any > freshly started consumer will automatically sync up to the current > state of the provider. > > -- > -- 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#6320)
by j＠telepaths.org 02 Oct '09

02 Oct '09

On Oct 2, 2009, at 23:00 , Howard Chu wrote: > j(a)telepaths.org wrote: >> My last email was likely indecipherable, so re-sending as plain text: >> >> ##### >> >> This may sound like a strange question, but couldn't seem to find the >> answer in the docs: >> >> Would the global "idletimeout" parameter interfere with >> 'refreshAndPersist' operations in any way? > > No, that would be stupid. > Yes Howard -- that would be incredibly stupid. But I had to ask. >> I ask because I have had yet another instance where my three >> production consumers did not get a series of updates that it should >> have. This was hours after successfully adding an accesslog database >> to all Provider servers in question. >> >> When querying the log database: >> >> ldapsearch -b cn=log -xD uid=log,cn=log -w logpassword -s sub -H ldap://ldap-provider-in-question >> >> I see that the records-in-question were in fact updated as they >> should >> have .... but there's absolutely no information hinting towards WHY a >> remote server would fail to get updates (especially when all LDAP >> traffic in between the said-hosts is unrestricted and unmoderated). > > Are you sure? No firewalls in the way? > SOME of the servers receiving updates are separated by firewalls, yes ... HOWEVER (a) there are special policies in place, allowing these hosts to communicate via LDAP[S]; this can be confirmed by running ldapsearch routines from every possible vantage point TO every possible provider, etc., and (b) some of the replication issues observed occurred when all affected hosts (one or more providers and its consumer clients) were in the same local subnet, at which point the firewall is immaterial. I had asked my stupid question about the idletimeout, because this behavior doesn't strike me as simply "not working". Rather, it begins to work .... then just stops. So my next thought was that perhaps the firewall was causing the connections to time-out. But if that were true ... wouldn't both the "retry" and the "timeout" parameters compensate for this? I mean, the man page certainly doesn't contradict my assumption ... Jeff >> Hence why I began to scrutinize the 'idletimeout' parameter >> (previously set to 45 seconds, now has been removed entirely from all >> Providers AND Consumers alike). >> >> Still looking at, testing and contemplating this whole situation ... >> I'll keep you posted, but am curious if anyone has any input to my >> question above, thanks. >> >> ##### >> >> I am officially out of ideas - synchronization is entirely >> unreliable. >> Need guidance ASAP. Thanks ..... > > -- > -- 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#6320)
by hyc＠symas.com 02 Oct '09

02 Oct '09

j(a)telepaths.org wrote: > IMPORTANT UPDATE: > > Is it normal for a 'slapd' server to correct itself via a restart of > the slapd process? Currently, I have one Consumer that is 2-records > behind in Synchronization - I restarted his process and the records > immediately were replicated. This normally is NOT standard behavior. > > Can anyone explain? Is this expected? Indicative of another problem? That's what the "refresh" in "refreshAndPersist" is about. Any freshly started consumer will automatically sync up to the current state of the provider. -- -- 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#6320)
by hyc＠symas.com 02 Oct '09

02 Oct '09

j(a)telepaths.org wrote: > My last email was likely indecipherable, so re-sending as plain text: > > ##### > > This may sound like a strange question, but couldn't seem to find the > answer in the docs: > > Would the global "idletimeout" parameter interfere with > 'refreshAndPersist' operations in any way? No, that would be stupid. > I ask because I have had yet another instance where my three > production consumers did not get a series of updates that it should > have. This was hours after successfully adding an accesslog database > to all Provider servers in question. > > When querying the log database: > > ldapsearch -b cn=log -xD uid=log,cn=log -w logpassword -s sub -H ldap://ldap-provider-in-question > > I see that the records-in-question were in fact updated as they should > have .... but there's absolutely no information hinting towards WHY a > remote server would fail to get updates (especially when all LDAP > traffic in between the said-hosts is unrestricted and unmoderated). Are you sure? No firewalls in the way? > Hence why I began to scrutinize the 'idletimeout' parameter > (previously set to 45 seconds, now has been removed entirely from all > Providers AND Consumers alike). > > Still looking at, testing and contemplating this whole situation ... > I'll keep you posted, but am curious if anyone has any input to my > question above, thanks. > > ##### > > I am officially out of ideas - synchronization is entirely unreliable. > Need guidance ASAP. Thanks ..... -- -- 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#6320)
by j＠telepaths.org 02 Oct '09

02 Oct '09

IMPORTANT UPDATE: Is it normal for a 'slapd' server to correct itself via a restart of the slapd process? Currently, I have one Consumer that is 2-records behind in Synchronization - I restarted his process and the records immediately were replicated. This normally is NOT standard behavior. Can anyone explain? Is this expected? Indicative of another problem? Jeff

1 0

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

02 Oct '09

My last email was likely indecipherable, so re-sending as plain text: ##### This may sound like a strange question, but couldn't seem to find the answer in the docs: Would the global "idletimeout" parameter interfere with 'refreshAndPersist' operations in any way? I ask because I have had yet another instance where my three production consumers did not get a series of updates that it should have. This was hours after successfully adding an accesslog database to all Provider servers in question. When querying the log database: ldapsearch -b cn=log -xD uid=log,cn=log -w logpassword -s sub -H ldap://ldap-provider-in-question I see that the records-in-question were in fact updated as they should have .... but there's absolutely no information hinting towards WHY a remote server would fail to get updates (especially when all LDAP traffic in between the said-hosts is unrestricted and unmoderated). Hence why I began to scrutinize the 'idletimeout' parameter (previously set to 45 seconds, now has been removed entirely from all Providers AND Consumers alike). Still looking at, testing and contemplating this whole situation ... I'll keep you posted, but am curious if anyone has any input to my question above, thanks. ##### I am officially out of ideas - synchronization is entirely unreliable. Need guidance ASAP. Thanks ..... Jeff

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 02 Oct '09

02 Oct '09

--On Friday, October 02, 2009 8:54 PM +0000 hyc(a)symas.com wrote: > strace is useless. Use gdb and get a trace of all running threads when > this occurs. > > http://www.openldap.org/faq/data/cache/59.html You also need to test against a current release of OpenLDAP, like OpenLDAP 2.4.18. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6321) segfault in 2.4.18 replica
by Howard Chu 02 Oct '09

02 Oct '09

Your trace shows pretty clearly that the crash occurred in your Kerberos library. You're going to need to start there to look for the problem.

1 0

Re: (ITS#6310) Slapd with pcache crashes under load
by hyc＠symas.com 02 Oct '09

02 Oct '09

karavelov(a)spnet.net wrote: > Full_Name: luben karavelov > Version: 2.4.18 - HEAD > OS: Debian Linux > URL: > Submission from: (NULL) (212.50.0.80) > > > Hello, > I have 2 running slapd servers for load balancing. The 2 instances are > configured with back-sql and pcache overlay. Every 5-15 minutes one of the > servers crashes. > > The config could be found here: > http://purgatory.spnet.net/~karavelov/slapd.conf.h2 > > A gdb session with the resulting core dump could be found here: > http://purgatory.spnet.net/~karavelov/gdb1 > > Without proxycache overlay the servers does not crash in this manner. > > The software tested is > 1. slapd 2.4.18 with backported pcache.c from HEAD > 2. slapd HEAD I haven't touched back-sql in quite a while, and don't have a suitable config for testing this. I suggest you run under valgrind and see what errors it reports. -- -- 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#6320)
by j＠telepaths.org 02 Oct '09

02 Oct '09

--Apple-Mail-4--815209214 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes This may sound like a strange question, but couldn't seem to find the answer in the docs: Would the global "idletimeout" parameter interfere with 'refreshAndPersist' operations in any way? I ask because I have had yet another instance where my three production consumers did not get a series of updates that it should have. This was hours after successfully adding an accesslog database to all Provider servers in question. When querying the log database: ldapsearch -b cn=log -xD uid=log,cn=log -w logpassword -s sub -H ldap://ldap-provider-in-question I see that the records-in-question were in fact updated as they should have .... but there's absolutely no information hinting towards WHY a remote server would fail to get updates (especially when all LDAP traffic in between the said-hosts is unrestricted and unmoderated). Hence why I began to scrutinize the 'idletimeout' parameter (previously set to 45 seconds, now has been removed entirely from all Providers AND Consumers alike). Still looking at, testing and contemplating this whole situation ... I'll keep you posted, but am curious if anyone has any input to my question above, thanks. Jeff On Oct 1, 2009, at 11:39 PM, Howard Chu wrote: > j(a)telepaths.org wrote: >> Sorry about that .... resending to ITS address: >> >> Regarding use of the accesslog DB ..... is this still an option when >> using 'mirrormode' ? I understand at least in the recent past, this >> option was not compatible with the accesslog overlay ..... > > That's not correct. The accesslog overlay can always be used for > logging purposes. It is just that using it for multimaster delta- > syncrepl is not yet supported. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --Apple-Mail-4--815209214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div>This may sound like a strange question, but couldn't seem to find = the answer in the docs:</div><div><br></div><div>Would the global = "idletimeout" parameter interfere with 'refreshAndPersist' operations in = any way?</div><div><br></div><div>I ask because I have had yet another = instance where my three production consumers did not get a series of = updates that it should have.  This was hours after successfully = adding an accesslog database to all Provider servers in = question.</div><div><br></div><div>When querying the log = database:</div><div><br></div><div style=3D"font-size: 14px; = ">ldapsearch -b cn=3Dlog -xD uid=3Dlog,cn=3Dlog -w logpassword -s sub -H = <a = href=3D"ldap://ldap-provider-in-question">ldap://ldap-provider-in-question= </a></div><div><br></div><div>I see that the records-in-question were in = fact updated as they should have .... but there's absolutely no = information hinting towards WHY a remote server would fail to get = updates (especially when all LDAP traffic in between the said-hosts is = unrestricted and unmoderated).  Hence why I began to scrutinize the = 'idletimeout' parameter (previously set to 45 seconds, now has been = removed entirely from all Providers AND Consumers = alike).</div><div><br></div><div>Still looking at, testing and = contemplating this whole situation ... I'll keep you posted, but am = curious if anyone has any input to my question above, = thanks.</div><div><br></div><div>Jeff</div><div><br></div><div><br></div><= div><br></div><br><div><div>On Oct 1, 2009, at 11:39 PM, Howard Chu = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div><a href=3D"mailto:j@telepaths.org">j(a)telepaths.org</a> = wrote:<br><blockquote type=3D"cite">Sorry about that .... =  resending to ITS address:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Regarding use = of the accesslog DB ..... is this still an option = when<br></blockquote><blockquote type=3D"cite">using 'mirrormode' ? =  I understand at least in the recent past, = this<br></blockquote><blockquote type=3D"cite">option was not compatible = with the accesslog overlay .....<br></blockquote><br>That's not correct. = The accesslog overlay can always be used for logging purposes. It is = just that using it for multimaster delta-syncrepl is not yet = supported.<br><br>-- <br>  -- Howard Chu<br>  CTO, Symas Corp. =           <a = href=3D"http://www.symas.com">http://www.symas.com</a><br> =  Director, Highland Sun     <a = href=3D"http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br> =  Chief Architect, OpenLDAP  <a = href=3D"http://www.openldap.org/project/">http://www.openldap.org/project/= </a><br></div></blockquote></div><br></body></html>= --Apple-Mail-4--815209214--

1 0

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