> 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 know > 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 :). > If you're up to gdb debugging, then the first step is to gdb slapd, and set > 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?
