openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7498) Openldap syncrepl issue
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, I would strongly advise retrying with a current OpenLDAP release. Numerous sync replication bugs have been fixed since 2.4.33. Also, to answer your earlier question, there's no such thing as "mirror mode". "mirror mode" is entirely a concept. A system either is or isn't multimaster, which delta-syncrepl works with. See also: <http://www.openldap.org/its/index.cgi/?findid=8511> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7474) memberOf and full syncreplication
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, As noted in the slapo-memberof(5) man page, it is unsafe for use with replication. See also <http://www.openldap.org/its/index.cgi/?findid=8613> for ways in which to replicate memberOf functionality in a replication safe manner using slapo-dynlist. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, I can say that I've not seen this issue in numerous current OpenLDAP deployments with OpenLDAP 2.4.44. However, be aware of ITS#8432 which does impact 2.4.44. I'd guess that whatever was causing the problem was fixed between 2.4.38 and 2.4.44. Unfortunately, a clear backtrace with full debugging symbols and no optimization of slapd was never provided, so work on this ITS can't really go forward. I will close it for now, given that I've not seen this issue impact large volume 3 & 4 way MMR setups with current releases. If you can reproduce with current OpenLDAP, please feel free to respond, at which time I will reopen the issue. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by hyc＠symas.com 03 Apr '17

03 Apr '17

henson(a)acm.org wrote: > So slapd crashed two days in a row, yesterday morning and this morning > :(. Same backtrace. You should probably switch to a non-optimized build. The backtrace you posted initially had most parameters optimized out, which also makes things harder to trace. -- -- 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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 03 Apr '17

03 Apr '17

So slapd crashed two days in a row, yesterday morning and this morning :(. Same backtrace. What's worse whereas unlike today and every time before it was relatively harmless, something *weird* happened yesterday. I did my usual of just restarting slapd on the master and letting the load balancer fail back over to it and having it catch back up on replication from the changes made to the secondary, which has always been fine before other than maybe having to tune up whatever change was in the middle of being committed when the primary actually died. But somehow yesterday things that happened like a week and a half ago just mysteriously disappeared 8-/. 10 groups that were created on 3/22 were just *gone* without a trace. I had to go dig up ldif backups from then and manually readd them back to the directory to clean stuff up. It looks like there's some group membership corruption too, I'm going to look at it in more detail tomorrow, it should be identical to our AD environment so I can compare and clean up against that. It doesn't look like any users fell into limbo, I diff'd the user DN's from the backup the day before against the one after and they're all still there modulo 5 that were deleted intentionally. I haven't been overly concerned about this issue, while it's been annoying, it hasn't had much of a production impact. But it just turned ugly :(, assuming this was caused by the crash, and I can't see how it wouldn't have been... <sigh>. Is there any logging or something I could turn on that would help for the next occurance but wouldn't be an excessive impact in terms of load or disk utilization on a production box? Thanks...

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 31 Mar '17

31 Mar '17

On Thu, Mar 30, 2017 at 12:30:09PM -0700, Paul B. Henson wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Monday, March 27, 2017 8:10 AM >>=20 >> I've had a look whether I could reproduce the issue somehow and there = is >> a potential crasher if the accesslog entry contained "reqmod: >> eduPersonAffiliation:+". Can you confirm whether you have entries like >> this in your logdb? >=20 > There aren't currently any entries like that in the log, although the l= ast > crash was a week or two ago. I will check again right after the next cr= ash. > However, here is one of the log entries that appeared to correlate with= what > was being processed in the backtrace of one of the crashes: >=20 > [...] >=20 > And it does not appear to have that signature. Hi Paul, "modify: replace" entries should result in modify_replace_values being called instead, where modify_add_values is called when the mod is LDAP_MOD_ADD (set up from reqMod values starting "attr:+"). Not sure if there is a way to reset the LDAPResult *msg in syncrepl_message_to_op to retrieve the entry from there but that would be the place I'd look when you get a another crash. Regards, --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 31 Mar '17

31 Mar '17

> From: Quanah Gibson-Mount > Sent: Thursday, March 30, 2017 5:16 PM > > 2.4.44+ITS8432. ;) So I think there's something specific to your use case > (the hardest kinds to track down!). * Specific to my use case - check * Not reproducible - check * Only occurs sporadically at randomly dispersed intervals - check Perhaps we've hit a heisenbug ;). I was kind of hoping it would get fixed by accident by other updates in the next release :).

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 31 Mar '17

31 Mar '17

--On Friday, March 31, 2017 1:05 AM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, March 30, 2017 3:14 PM >> >> released. In addition, this very bug report indicates a regression >> between 2.4.44 and what's currently scheduled for 2.4.45, which is >> further reasoning not to release 2.4.45 at this time. > > Hmm, I started seeing this problem when I upgraded from 2.4.43 to > 2.4.44+ITS 8432 patch. I've never run stock 2.4.44; so I can't say > whether this issue would occur without the ITS 8432 patch... Either way, it's a significant regression that needs fixing before I'd be comforable with a 2.4.45 release. Interestingly, I never saw this problem @ Zimbra, even though it is constantly modifying data and has 2.4.44+ITS8432. ;) So I think there's something specific to your use case (the hardest kinds to track down!). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 31 Mar '17

31 Mar '17

> From: Quanah Gibson-Mount > Sent: Thursday, March 30, 2017 3:14 PM > > released. In addition, this very bug report indicates a regression between > 2.4.44 and what's currently scheduled for 2.4.45, which is further > reasoning not to release 2.4.45 at this time. Hmm, I started seeing this problem when I upgraded from 2.4.43 to 2.4.44+ITS 8432 patch. I've never run stock 2.4.44; so I can't say whether this issue would occur without the ITS 8432 patch...

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 31 Mar '17

31 Mar '17

--On Thursday, March 30, 2017 8:20 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Monday, March 27, 2017 8:09 AM >> >> There's too many outstanding issues to release 2.4.45, including this >> one. > > Well, are those new issues that don't exist in 2.4.44, or simply existing > bugs already in the wild that haven't been fixed? If the former, then > certainly you don't want to release fresh bugs 8-/, but if the latter, it > seems to me that pushing a release that improves the state of production > by fixing some known bugs, even if other existing known bugs still remain > to be quashed, is preferable than leaving a larger number of known bugs > at large on production systems :(. It seems the circular replication bug > is particularly bad, I'm surprised more people aren't having issues with > it. 2.4.43 introduced new bugs and those were continued in 2.4.44. I think it's important that the regressions are addressed before 2.4.45 is released. In addition, this very bug report indicates a regression between 2.4.44 and what's currently scheduled for 2.4.45, which is further reasoning not to release 2.4.45 at this time. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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