Bug 824014 - DS Shuts down intermittently
Summary: DS Shuts down intermittently
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.3
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 826592
TreeView+ depends on / blocked
 
Reported: 2012-05-22 15:01 UTC by Namita Soman
Modified: 2012-06-20 07:15 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.2.10.2-15.el6
Doc Type: Bug Fix
Doc Text:
Cause: Performing delete and search operations against the directory server under a high load with entryusn, memberof, and referential integrity enabled. Consequence: Directory server crashes. Fix: The entryusn code was modifying the entry in the cache directly. If a search thread was access the entry at the same time, the server would crash. The fix is to never modify the entry directly in the cache. Result: Server does not crash when performing searches and deletions while under a high load with entryusn, memberof, and referential integrity enabled.
Clone Of:
Environment:
Last Closed: 2012-06-20 07:15:47 UTC
Target Upstream Version:


Attachments (Terms of Use)
trace back (7.39 KB, text/plain)
2012-05-22 16:14 UTC, Namita Soman
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0813 normal SHIPPED_LIVE Low: 389-ds-base security, bug fix, and enhancement update 2012-06-19 19:29:15 UTC

Description Namita Soman 2012-05-22 15:01:06 UTC
Description of problem:
When running the UI tests, we see 'Internal Server Error'. 
ipactl status indicated Dir srv is not running.

Put debug in place, and rich is investigating

Version-Release number of selected component (if applicable):
ipa-server-2.2.0-14.el6.x86_64
389-ds-base-1.2.10.2-13.el6.x86_64

How reproducible:
intermittently

Steps to Reproduce:
1. Cannot recreate always
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Namita Soman 2012-05-22 16:14:09 UTC
Created attachment 586071 [details]
trace back

Comment 2 Rich Megginson 2012-05-22 21:17:51 UTC
The problem appears to be related to entryusn/preventryusn.  The usn bepreop modifies the entry in the cache directly.  If another thread doing a search happens to read the attribute list after preventryusn has been added by usn_bepreop_delete/_usn_add_next_usn, it will crash.  I think the solution to this crash will be to _not_ modify the entry in the cache.

Comment 3 Rich Megginson 2012-05-23 00:29:27 UTC
Was able to reproduce - it is very similar to https://bugzilla.redhat.com/show_bug.cgi?id=813964 - used almost the same steps except for step 1 - instead of setting up mmr, set up a single server with entryusn, referint, and memberof enabled.  The rest of the steps are the same.

Comment 4 Rich Megginson 2012-05-23 01:14:37 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/382

Comment 8 Rich Megginson 2012-05-25 00:00:50 UTC
    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 search operations against the directory server under a high load with entryusn, memberof, and referential integrity enabled.
Consequence: Directory server crashes.
Fix: The entryusn code was modifying the entry in the cache directly.  If a search thread was access the entry at the same time, the server would crash.  The fix is to never modify the entry directly in the cache.
Result: Server does not crash when performing searches and deletions while under a high load with entryusn, memberof, and referential integrity enabled.

Comment 9 Namita Soman 2012-05-31 02:20:21 UTC
Ran same UI tests as above with ipa-server-2.2.0-16.el6.x86_64 and 389-ds-base-1.2.10.2-15.el6.x86_64, and didn't see the issue.

Comment 10 errata-xmlrpc 2012-06-20 07:15:47 UTC
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


Note You need to log in before you can comment on or make changes to this bug.