Bug 811291
| Summary: | [abrt] 389-ds-base-1.2.10.4-2.fc16: index_range_read_ext: Process /usr/sbin/ns-slapd was killed by signal 11 (SIGSEGV) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Rich Megginson <rmeggins> |
| Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
| Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3 | CC: | jgalipea, mreynolds, nkinder, shaines, sramling |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.2.10.2-6.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: Performing delete and ranged search operations against the directory server under a high load.
Consequence: Directory server crashes.
Fix: Entries may be deleted out from under a ranged search request. Server should handle this case by not returning deleted entries and not crashing.
Result: Server does not crash when performing range searches and deletions while under a high load.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 07:15:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Rich Megginson
2012-04-10 16:02:16 UTC
Please add steps to reproduce/verify Steps to reproduce/verify: 1) set up two masters for multi-master replication 2) enable the USN plugin on both servers 3) add indexes for uidNumber and gidNumber e.g. dn: cn=uidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectclass: top objectclass: nsIndex cn: uidnumber nssystemindex: false nsindextype: eq nsmatchingrule: integerOrderingMatch dn: cn=gidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectclass: top objectclass: nsIndex cn: gidnumber nssystemindex: false nsindextype: eq nsmatchingrule: integerOrderingMatch in a separate shell/window, do the following: usn=0 ; while [ 1 ] ; do ii=100 ; while [ $ii -gt 0 ] ; do ii=`expr $ii - 1` ; ldapsearch -xLLL -h localhost -p PORTNUMBEROFMASTER2 -D "cn=directory manager" -w password -b dc=example,dc=com -E pr=100/noprompt '(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*)(entryusn>='$usn')(!(entryusn='$usn')))' > /dev/null 2>&1 & done ; wait ; done That is, do 100 ldapsearch processes all doing a simple paged range search, and wait for them all to complete, then do it again in another shell/window, add 1000 posix users like this: dn: uid=testuser$ii,ou=people,dc=example,dc=com objectclass: inetOrgPerson objectclass: posixAccount cn: Test User$ii sn: User$ii uidNumber: 500$ii gidNumber: 500$ii homeDirectory: /home/testuser$ii confirm that all users are replicated to both servers next, delete all 1000 users - I do something like this: ii=1000 ; while [ $ii -gt 0 ] ; do dn="uid=testuser$ii,ou=people,dc=example,dc=com" ldapdelete -x -h localhost -p PORTNUMBEROFMASTER1 -D "cn=directory manager" -w password "$dn" ii=`expr $ii - 1` done Usually you will see the ldapsearches complete with a message of "Done ..." - if you see them complete with an message like "Exit: 255 ..." or "Error: ..." that usually means the server has crashed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause: Performing delete and ranged search operations against the directory server under a high load.
Consequence: Directory server crashes.
Fix: Entries may be deleted out from under a ranged search request. Server should handle this case by not returning deleted entries and not crashing.
Result: Server does not crash when performing range searches and deletions while under a high load.
As given in comment #3, I ran simplepaged ldapsearch, ldapdelete in multiple threads. I didn't see any crash in the server. Hence, marking the bug as Verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0813.html |