Bug 1273552
| Summary: | Deadlock between two MODs on the same entry between entry cache and backend lock | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Noriko Hosoi <nhosoi> |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | unspecified | Docs Contact: | Petr Bokoc <pbokoc> |
| Priority: | unspecified | ||
| Version: | 6.6 | CC: | amsharma, jgalipea, nkinder, pbokoc, rmeggins, tbordaz |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.2.11.15-67.el6 | Doc Type: | Bug Fix |
| Doc Text: |
*389-ds-base* no longer hangs due to modified entry remaining locked
During a modify operation, the modified entry is inserted into entry cache and locked until the modified entry is returned. In cases where the entry is removed from the entry cache after it is committed but before the return operation, the modified entry previously remained locked, and any subsequent write operations on the same entry then caused the server to hang. This bug has been fixed by adding a flag so that the entry can be unlocked whether it is present in the entry cache or not, and the server no longer hangs in this situation.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-05-10 19:22:01 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
Noriko Hosoi
2015-10-20 16:51:41 UTC
Hi Amita, I used a IPA CI test (more specifically a KRA test). I updated the upstream ticket with the details how to run the tests in https://fedorahosted.org/389/ticket/47978#comment:19 thanks thierry (In reply to thierry bordaz from comment #3) > Hi Amita, > > I used a IPA CI test (more specifically a KRA test). > I updated the upstream ticket with the details how to run the tests in > https://fedorahosted.org/389/ticket/47978#comment:19 Thanks Thierry, I did some investigation and discussed with Kaleem about it. Above mentioned test is designed for RHEL7 (involved vault), and not for rhel6. Here is the job which failed, for rhel6 for the test case - https://beaker.engineering.redhat.com/jobs/1187968 So, can you please mention how it can be tested on rhel6. Thanks & Regards, Amita > > thanks > thierry Hi Amita, The bug is dynamic. DS is using an entry cache and the bug occurs if an entry was in the entry cache during the update but no longer in the entry cache at the end of the update. This is something difficult to acheive. I think you can try to reproduce with something like: - provision 1000 entries - stop DS, set nsslapd-cachesize=10, start DS - run load of unindexed searches or simple lookup all the entries - Then during the load, do an update on an entry (it can be always the same entry). This test case can be sufficient to reproduce but it is difficult to be sure it will succeeds. thanks theirry Followed steps in comment#5 [root@vm-idm-001 export]# rpm -qa | grep 389 389-ds-base-1.2.11.15-72.el6.x86_64 389-ds-base-libs-1.2.11.15-72.el6.x86_64 [root@vm-idm-001 export]# i=10; while [ $i > 10 ]; do ldapsearch -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "dc=example,dc=com"; i=`expr $i - 1`; done [root@vm-idm-001 ~]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF dn: uid=FBechtel998,ou=Accounting,dc=example,dc=com changetype: modify replace: employeeType employeeType: Super EOF modifying entry "uid=FBechtel998,ou=Accounting,dc=example,dc=com" [root@vm-idm-001 ~]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF dn: uid=FBechtel998,ou=Accounting,dc=example,dc=com changetype: modify replace: employeeType employeeType: Supe1r EOF modifying entry "uid=FBechtel998,ou=Accounting,dc=example,dc=com" [root@vm-idm-001 ~]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF dn: uid=FBechtel998,ou=Accounting,dc=example,dc=com changetype: modify replace: employeeType employeeType: Supe1r1 EOF modifying entry "uid=FBechtel998,ou=Accounting,dc=example,dc=com" [root@vm-idm-001 ~]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF dn: uid=FBechtel998,ou=Accounting,dc=example,dc=com changetype: modify replace: employeeType employeeType: Supe1r11 EOF modifying entry "uid=FBechtel998,ou=Accounting,dc=example,dc=com" [root@vm-idm-001 ~]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF dn: uid=FBechtel998,ou=Accounting,dc=example,dc=com changetype: modify replace: employeeType employeeType: Supe1211 EOF modifying entry "uid=FBechtel998,ou=Accounting,dc=example,dc=com" Nothing seems to fail here, marking 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. https://rhn.redhat.com/errata/RHBA-2016-0737.html |