openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6320)
by hyc＠symas.com 03 Oct '09

03 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

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

02 Oct '09

helge(a)monsternett.no wrote: > Full_Name: Helge Milde > Version: slapd 2.4.11 > OS: Debian 5 > URL: > Submission from: (NULL) (81.175.2.164) > > > Hello, > > In the last two days, slapd has randomly stopped working on our server, about > one time every two or three hours. Before this, slapd had been running without > any problems for about two months. slapd.conf has not been touched since then. > > What happens is that slapd stops taking queries (postfix, dovecot, NSS etc. > starts getting timeouts), and it starts using exactly 100% of one core until we > restart it. > After restart, everything works again (until this happens again). > > It seems to only happen when slapd is under "stress" (we have an 8-core system > with 8G RAM, and so slapd is really never under much "stress"; the biggest CPU > load I've seen is about 40% on one core). The last ldap search before slapd > stops working is always the same: > Oct 2 10:57:38 oi-mail slapd[24550]: conn=1543 op=1 SRCH > base="ou=groups,dc=web,dc=xxxx,dc=net" scope=1 deref=0 > filter="(&(objectClass=posixGroup))" > .. which should return about 1800 entries. Different connections might query > this simultaneously, and it's a query that happens every ~10 seconds on > average. > > I've tried to reproduce this by doing .. > # while [ 1 ]; do ldapsearch -x -H ldaps://.. -b > 'ou=groups,dc=web,dc=xxxx,dc=net' '(&(objectClass=posixAccount))'; done > .. for two minutes without any "luck" :). slapd just uses a bit more CPU, but > never stops working. > > With "loglevel stats stats2", I get nothing out of the logs: > Oct 2 08:42:15 oi-mail slapd[15836]: conn=34798 op=1 ENTRY > dn="cn=xxxx,ou=groups,dc=web,dc=xxxx,dc=net" > ... time of "crash" (we're mid-search at this point); nothing gets logged until > we do a restart: ... > Oct 2 08:42:30 oi-mail slapd[15836]: daemon: shutdown requested and initiated. > Oct 2 08:42:30 oi-mail slapd[15836]: conn=34391 fd=31 closed (slapd shutdown) > ... many entires like the one above, and then I seem to be getting the next > entry from the same connection, right before it closes: ... > Oct 2 08:42:30 oi-mail slapd[15836]: conn=34798 op=1 ENTRY > dn="cn=xxxx,ou=groups,dc=web,dc=xxxx,dc=net" > Oct 2 08:42:30 oi-mail slapd[15836]: conn=34798 fd=81 closed (slapd shutdown) > > I've tried logging more than just stats, but the interesting loglevels also > causes a big performance hit (trace and args), and I'm not really sure which of > the other loglevels could be helpful. > This is a live ldap server, on a server that also hosts other services, so I > simply can't take the performance hit. > > I also did a strace -p<slapd pid>, which only gives "futex(0x41c499e0, > FUTEX_WAIT," until I restart slapd, but the "restarting routine" could be > useful, so here it is: http://www.pastie.org/639170 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 -- -- 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

(ITS#6323) smbk5pwd: Makefile links module for a different directory than it's installed to
by jonathan＠phillipoux.net 02 Oct '09

02 Oct '09

Full_Name: Jonathan Clarke Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-smbk5pwd-rpath-20091002.pat… Submission from: (NULL) (82.67.204.30) Greetings, The makefile in the smbk5pwd contrib module runs the libtool link phase with rtool=$(libdir), but then installs the module to $(moduledir), which can be different, and thus causes install to bork: ../../../libtool --mode=install cp smbk5pwd.la /usr/lib/openldap libtool: install: error: cannot install `smbk5pwd.la' to a directory not ending in /usr/lib The patch above fixes this, removing libdir completely from the Makefile as it doesn't seem to be needed.

1 0

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

02 Oct '09

OK I have a fully-functional accesslog configured on all applicable Provider servers. The respective DIT is now being watched for all WRITES (delete, add, modify and modrdn). I made a change a few minutes ago to a test record, and it DID replicate to ALL slapd servers, so we're looking good in the "short- term". I will check back with you guys later today with any developments, but we should know if there's still a problem today, and maybe now I can get some visibility into it. Thanks again to both of you, Howard and Quanah. Jeff

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs