Bug 1824930
| Summary: | ipa ns-slapd 3 threads deadlock, db pages, state_change lock, write vattr lock | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Marc Sauton <msauton> | |
| Component: | 389-ds-base | Assignee: | thierry bordaz <tbordaz> | |
| Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | |
| Severity: | high | Docs Contact: | Marc Muehlfeld <mmuehlfe> | |
| Priority: | high | |||
| Version: | 7.6 | CC: | jwooten, mreynolds, pasik, spichugi, tbordaz, tmihinto, vashirov | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | 389-ds-base-1.3.10.2-3.el7 | Doc Type: | Bug Fix | |
| Doc Text: |
.Directory Server no longer hangs while updating the schema
Previously, during a mixed load of search and modify operations, the update of the Directory Server schema blocked all search and modify operations, and the server appeared to hang. This update adjusts the mutex locking during schema updates. As a result, the server does not hang while updating the schema.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1839173 (view as bug list) | Environment: | ||
| Last Closed: | 2020-09-29 19:46:56 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: | 1839173 | |||
|
Comment 7
Marc Sauton
2020-05-05 00:51:26 UTC
upstream ticket https://pagure.io/389-ds-base/issue/51068 Fix pushed upstream => POST Hello, I am watching the RedHat IT case, do we have a fix we can provide to our customers? Thanks, I can look into that, but at a glance, the RHEL-7 389-ds-base hotfix would be for 1.3.10 , not 1.3.9 I made a RHEL-7.8 389-ds-base-1.3.10 hotfix , attached to the sf case number 02643823 , not much testing done on it. I am trying to do a RHEL-7.7 389-ds-base-1.3.9 hotfix , but the koji build command I used a few minutes earlier correctly, cannot reach http://brewweb.devel.redhat.com/ at the moment, not sure what is going on. Hello, The fix https://pagure.io/389-ds-base/issue/51068 is easy to backport and Marc made a hotfix [1]. I initially thought the bug was rare but I am probably wrong as it happened several time recently. There is not workaround, the trigger (update of schema) can not be prevented but I think to mitigate the risk any change of schema (direct ldapmodify or upgrade of an instance with new schema) should preferably done during calm period. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1824930#c13 I made another hotfix for RHEL-7.7 389-ds-base-1.3.9.1-10 , waiting on feedback. there was some internal outage this weekend. Build tested: 389-ds-base-1.3.10.2-5.el7.x86_64 Steps: 1. Add 4000 entries: ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r0 -R4000 2. Set small entry cache and restart dirsrv: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cache-autosize nsslapd-cache-autosize: 0 - replace: nsslapd-dbcachesize nsslapd-dbcachesize: 512001 - 3. Start search and mod loads in a different terminal: ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e esearch,incr,commoncounter -r0 -R4000 ldclt -D "cn=Directory Manager" -w password -f cn=userXXXXX -b "ou=people,dc=example,dc=com" -e incr,commoncounter,attreplace=description:valueXXXXXXXXXX -r0 -R4000 4. Do a schema mod: cat schema-mod.ldif dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 8.9.10.11.12.13.14 NAME 'MozAttribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Mozilla Dummy Schema' ) - add: objectclasses objectclasses: ( 1.2.3.4.5.6.7 NAME 'MozillaObject' SUP top MUST ( objectclass $ cn ) MAY ( MozAttribute ) X-ORIGIN 'user defined' )" - ldapmodify -D cn=directory\ manager -w password -f schema-mod.ldif With 389-ds-base-1.3.10.2-3.el7.x86_64 schema mod operation would hang indefinitely. With 389-ds-base-1.3.10.2-5.el7.x86_64 schema mod operation completes immediately. Marking 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 (389-ds-base bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:3894 |