--On May 8, 2014 at 3:43:06 PM -0700 Quanah Gibson-Mount
>>> You can gdb slapd, and manually fix the serverID in the
>> or you can restart all your slapd servers.
> How are you detecting when it starts? On my dev system, the first symptom
> is massive memory use by the slapd process, followed by an alert that the
> accesslog db is over 80% full. Then slapd processes start getting killed
> off by the OOM mechanism and my dev environment basically implodes. If it
> happened in production, odds are I wouldn't catch it in time to keep
> things from going south. How do you trim out the extremely large number
> of duplicate entries in the accesslog when you are cleaning up after an
> occurrence in one of your production environments?
The massive memory consumption would be due to the switch to refresh
mode. On the environments I've been using, OOM is disabled (horrible
concept), so there's no killing of slapd itself. As for cleaning the
accesslog, I stop all servers, move it aside, and restart (it'll create a
new accesslog db).
> Hopefully the underlying issue will be sorted out soon. I'm just going to
> tell our security guys they are not going to get their account lockouts
> as long as the password policy module puts my dev environment into
> conniptions :).
Yeah, it isn't specific to ppolicy because I don't use it. I'm trying to
get this happening in my dev env now.
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 need to
find a way to reliably trigger the problem so it can be debugged under GDB.
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.
Zimbra :: the leader in open source messaging and collaboration