--On May 8, 2014 at 3:07:23 PM -0700 "Paul B. Henson" <henson(a)acm.org>
> From: Quanah Gibson-Mount
> Sent: Tuesday, May 06, 2014 9:43 PM
> > beginning, and will see if it does it again. When it happens to your
> > client in production, how do you resolve it?
> You can gdb slapd, and manually fix the serverID in the syncinfo
> 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
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
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.
Off-topic, is there a secret handshake for the developer list or
;)? The couple of messages I posted after I subscribed still haven't shown
up, and a couple of inquiries I made on this list about the moderation on
that list were never responded to <sigh>...
Nope... I think I have moderator privs even, but I don't recall where I
have to log into to do it. :/ There's a couple of people I can bug about
Zimbra :: the leader in open source messaging and collaboration