Bug 824014
| Summary: | DS Shuts down intermittently | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Namita Soman <nsoman> | ||||
| Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> | ||||
| Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 6.3 | CC: | arubin, dpal, jgalipea, mkosek, syeghiay | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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 07:15:47 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 826592 | ||||||
| Attachments: |
|
||||||
|
Description
Namita Soman
2012-05-22 15:01:06 UTC
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 |