openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, problems: slapd just crashed for no apparent reason. slapd[8131]: segfault at 433e8a00 ip 433e8a00 sp 433e89a8 error 15 Not good. What version of slapd should I be using to guarantee: * No deadlocks * No replication errors * No SEGFAULTS It just seems like one buggy slapd release after another. Never happened with 2.3 releases ..... Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

My apologies On Oct 15, 2009, at 10:26 , Quanah Gibson-Mount wrote: > --On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org > > wrote: > >> Thank you Gibson, my checkpoints (both definitions) have not changed >> since you last asked, but the fact that it can help with shutdown >> times >> is a very useful tip, thanks! >> >> Jeff > > Just to note, my first name is "Quanah", not "Gibson". "Gibson- > Mount" is my last name. > > Which is why I sign my emails thusly: > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 10:19 AM -0700 Jeff Doyle <j(a)telepaths.org> wrote: > Thank you Gibson, my checkpoints (both definitions) have not changed > since you last asked, but the fact that it can help with shutdown times > is a very useful tip, thanks! > > Jeff Just to note, my first name is "Quanah", not "Gibson". "Gibson-Mount" is my last name. Which is why I sign my emails thusly: --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

Thank you Gibson, my checkpoints (both definitions) have not changed since you last asked, but the fact that it can help with shutdown times is a very useful tip, thanks! Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by quanah＠zimbra.com 15 Oct '09

15 Oct '09

--On Thursday, October 15, 2009 4:50 PM +0000 j(a)telepaths.org wrote: > OK, I believe the dead-lock issue is solved, however OCCASIONALLY when > attempting a restart or stop of the slapd process, it throws an error > saying 'slapd stop failed', however the slapd process does quit as > expected, so its a "false failure". > > The one possibility for the reason this is happening, aside from > blaming slapd, is that my two test boxes are VMs ... so I kind of > expect sluggish responses, especially on a VMware server as busy as > ours. I will note that our production LDAP servers are NOT VMs and > will never be ;-) > > I believe you were correct, Pierangelo. I will post my findings over > the next fews days to keep everyone in the loop. Probably the issue. Make sure you have checkpoints defined for all bdb/hdb databases as well, which will help with shutdown times. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, I believe the dead-lock issue is solved, however OCCASIONALLY when attempting a restart or stop of the slapd process, it throws an error saying 'slapd stop failed', however the slapd process does quit as expected, so its a "false failure". The one possibility for the reason this is happening, aside from blaming slapd, is that my two test boxes are VMs ... so I kind of expect sluggish responses, especially on a VMware server as busy as ours. I will note that our production LDAP servers are NOT VMs and will never be ;-) I believe you were correct, Pierangelo. I will post my findings over the next fews days to keep everyone in the loop. Thanks, Jeff

1 0

Re: (ITS#6330) slapd memory leak
by whm＠stanford.edu 15 Oct '09

15 Oct '09

> Apparently, accessing that URL requires a valid account. In any case, you > should run slapd under valgrind for a while, in order to locate the leak. Sorry about that. The URL should be accessible now. I will start the valgrind work a bit later this morning on the left coast. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6329) memberof overlay doesn't update entryCSN
by msmith＠cbnco.com 15 Oct '09

15 Oct '09

On Wed, 14 Oct 2009, masarati(a)aero.polimi.it wrote: > Should be fixed in HEAD (one-line fix, see overlays/memberof.c 1.25 -> 1.26). > > Please test. Thanks, p. Thanks - I applied this to openldap 2.4.19 and the entryCSNs now match on all nodes, as long as they're all up when a group is modified. I still get something strange if one node is down: if I remove a user from a group on the working node, then bring the failed node back, the failed node doesn't sync the modified group and user objects. For example, if I remove testuser3 from testgroup2 while node 2 is down, then bring node 2 back, I get this on node 1: dn: uid=testuser3,ou=people,dc=dom memberOf: cn=testgroup1,ou=group,dc=dom entryCSN: 20091015040419.455869Z#000000#001#000000 dn: cn=testgroup2,ou=group,dc=dom member: uid=testuser2,ou=people,dc=dom entryCSN: 20091015040419.455869Z#000000#001#000000 And this on node 2: dn: uid=testuser3,ou=people,dc=dom memberOf: cn=testgroup2,ou=group,dc=dom memberOf: cn=testgroup1,ou=group,dc=dom entryCSN: 20091015033445.046089Z#000000#002#000000 dn: cn=testgroup2,ou=group,dc=dom member: uid=testuser2,ou=people,dc=dom member: uid=testuser3,ou=people,dc=dom entryCSN: 20091015033233.354687Z#000000#001#000000 I don't have this problem with changes that don't involve member/memberOf attributes. For example, I can add a description attr to the group object while node 2 is down, and when I bring it back up, it picks up the change. On both nodes I've got the memberof and syncprov overlays turned on, in that order. dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}memberof dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {1}syncprov Thanks, Mike

1 0

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

15 Oct '09

OK, for anyone following this thread, please refer to ITS #6331, as I believe this issue may not be a "replication issue" at all, rather a deadlock PREVENTING replication. Might as well close this ticket, thanks for everyone's help. Jeff

1 0

Re: (ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 15 Oct '09

15 Oct '09

OK, I was able to compile a set of Debian packages for version 2.4.19 using the source obtained from openldap.org. I have set up a mirror of our production environment (less a few servers). I have two provider servers in mirrormode, and configured for multimaster syncrepl. So far, no locks, no replication issues, everything seems peachy. Though, in real-life, the problem has a tendency to reappear sometimes a week after a slapd-restart. We'll see what happens. I will continue to update this ticket, detailing any further developments. Thanks again Pierangelo and Gibson, I appreciate your help. 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