Bug 824014 - DS Shuts down intermittently
DS Shuts down intermittently
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.3
Unspecified Unspecified
urgent Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
IDM QE LIST
:
Depends On:
Blocks: 826592
  Show dependency treegraph
 
Reported: 2012-05-22 11:01 EDT by Namita Soman
Modified: 2012-06-20 03:15 EDT (History)
5 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 03:15:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Namita Soman 2012-05-22 11:01:06 EDT
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 12:14:09 EDT
Created attachment 586071 [details]
trace back
Comment 2 Rich Megginson 2012-05-22 17:17:51 EDT
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-22 20:29:27 EDT
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-22 21:14:37 EDT
Upstream ticket:
https://fedorahosted.org/389/ticket/382
Comment 8 Rich Megginson 2012-05-24 20:00:50 EDT
    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-30 22:20:21 EDT
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 03:15:47 EDT
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.