Hide Forgot
Created attachment 477123 [details] Stack trace Description of problem: The process on the replica crashes. Version-Release number of selected component (if applicable): A master server running 1.2.7.5, replicating to a server running 1.2.7.5. Same hardware and software installation. How reproducible: Every time. We have 10 replicas. Each one running 1.2.7.5 will crash after some amount of time (few minutes to an hour). Steps to Reproduce: 1. Enable replication from 1.2.7.5 master to 1.2.7.5 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. Actual results: Expected results: Additional info: 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 1.2.7.5, still stable). The server running 1.2.7.5 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 dn: 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.
To ssh://git.fedorahosted.org/git/389/ds.git a123b54..1980427 master -> master commit 1980427b8c78e79982c056ac270c6c3b11188830 Author: Rich Megginson <rmeggins> Date: Wed Feb 9 14:54:29 2011 -0700 Reviewed by: nkinder, nhosoi (Thanks!) Branch: master 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 To ssh://git.fedorahosted.org/git/389/ds.git 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!
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? Thanks, Amita
(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. > > Thanks, > Amita