--On May 13, 2014 at 2:08:30 PM -0700 "Paul B. Henson" <henson(a)acm.org>
> From: Quanah Gibson-Mount
> Sent: Monday, May 12, 2014 7:00 PM
> I haven't had any luck in reproducing it in my lab. I'd be curious to
> if you could share your cn=config setup (minus rootdn passwords), and
> describe how you are triggering the ppolicy updates in the lab.
I'll send you my config off list. The first time this happened, I had
enabled the password policy module and configured two policies, one as
default, and one explicitly configured on about a dozen service accounts.
I played with that for about an hour until I realized the authentication
failure granularity was insufficient to meet our account lockout needs.
Then it just sat basically idle, and maybe 6-8 hours later it started
ramping up memory use and blew up. The second time, I reloaded our dev
environment with a snapshot of production data, and started it up with
the password policy module loaded, but no actual password policies
defined. Once again, within a few hours it started spinning. I'll see if
I can get some minimal configuration that reliably reproduces this
failure, I don't think our ISO would be on board with shipping you a copy
of our production data :).
That's interesting... it was totally idle (doing nothing at all?).
> If you're up to gdb debugging, then the first step is to gdb
> a watchpoint on the serverID, so you can see at which point it gets set
> to '0' instead of the the correct sid value.
My current binaries don't have debugging symbols, but I will build a
binary with debugging enabled and give it a try if I get the time. So you
mean the slap_serverID variable defined in servers/slapd/ctxcsn.c?
No, s_sid in the syncops struct in syncprov.c. That is what was flipping
from [1|2|3] -> 0 on my systems.
Zimbra :: the leader in open source messaging and collaboration