Created attachment 477123 [details]
Description of problem:
The process on the replica crashes.
Version-Release number of selected component (if applicable):
A master server running 188.8.131.52, replicating to a server running 184.108.40.206. Same hardware and software installation.
Every time. We have 10 replicas. Each one running 220.127.116.11 will crash after some amount of time (few minutes to an hour).
Steps to Reproduce:
1. Enable replication from 18.104.22.168 master to 22.214.171.124 slave
2. Initialize replica (this I believe works fine with no crash every time)
3. Allow queries against replica
4. Replica will crash, some times almost immediately and some times after 30 or so minutes.
All servers running a pretty bare installation of CentOS 5.5 with all updates.
Nothing relevant in the access or error logs (at level 8192), although I haven't turned off access log buffering yet.
I can't tell yet if it is query related, replication related, or something else. Same servers rolled back to version 1.2.4 do not crash (master left at 126.96.36.199, still stable). The server running 188.8.131.52 also gets end-user queries, so the data and queries being the same, the only difference is that one is a master and the others are replicas, with only the replicas crashing.
I was able to reproduce the crash with openldap ldapmodify on EL5.
1) You have to have a client capable of sending an empty modify request - mozldap ldapmodify will not let you do this, but openldap ldapmodify will:
# /usr/bin/ldapmodify -x <<EOF
It will warn, but allow the modify through.
2) You have to be using a server built with mozldap - servers built with openldap will return an LDAP error when receiving an empty modify request
3) Either the modify operation is replicated, or the server has set cn=config nsslapd-lastmod: off
If these conditions are met, the empty modify operation will crash the server.
a123b54..1980427 master -> master
Author: Rich Megginson <email@example.com>
Date: Wed Feb 9 14:54:29 2011 -0700
Reviewed by: nkinder, nhosoi (Thanks!)
Fix Description: Check the modifications after lastmod is applied, if any.
If there are still no mods to apply, just return LDAP_SUCCESS to the client
and end the modify request. This makes it so that an empty modify is
allowed, but no further processing is done to avoid code that may not deal
with mods == NULL.
I also found a problem with the way an empty modify was handled. OpenLDAP
does not return an explicit error code if there was a problem reading the
sequence of modify ops, so we have to resort to other checking. This allows
an empty modify to pass through, when using either mozldap or openldap.
Platforms tested: RHEL5 x86_64, RHEL6 x86_64
Flag Day: no
Doc impact: no
5d4895c..a33cb58 389-ds-base-1.2.8 -> 389-ds-base-1.2.8
Can I remove the Security tag on this bug?
I suppose you could, since this isn't a top-level bug, but is there a particular reason why you wanted to?
(In reply to comment #22)
> I suppose you could, since this isn't a top-level bug, but is there a
> particular reason why you wanted to?
To make it publicly visible?
Oh, you mean the group visibility settings (I thought you meant to remove the Security keyword).
I'll remove the security group so that the bug will be public.
Yes, that's what I meant. Thanks!
I saw "the bug does not apply to RHDS 8.2.
The only affected 389 versions are 1.2.7 for EL5 and FC13."
Should I verify this and how?
(In reply to comment #26)
> Hi Rich,
> I saw "the bug does not apply to RHDS 8.2.
> The only affected 389 versions are 1.2.7 for EL5 and FC13."
> Should I verify this and how?
Since it doesn't affect RHEL6, just mark this as Upstream verified.