Hide Forgot
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:
Created attachment 586071 [details] trace back
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.
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.
Upstream ticket: https://fedorahosted.org/389/ticket/382
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.
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.
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