Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
During stress test of subtree renames a workaround was temporarily applied that changed the type of referential integrity plugin from betxnpostoperation to postoperation to suppress a problem described in bug 1082542. The following procedure was used:
1. Stop the server
2. Update the nsslapd-db-locks in dse.ldif
3. Create the entries (users and groups)
4. Start the server
5. modify referential integrity to postoperation
6. Run the test
7. Remove the suffix at the end
8. Modify the referential integrity plugin type back to betxnpostoperation
9. Restart the server
Multitude of effects occurred. There were several messages from CoS cache such as
cos_cache_change_notify: modified entry is NULL--updating cache just in case,
referential integrity plugin didn't log any error messages, removing ldbm entry and mapping tree entry resulted in 'ldap_delete: Operation not allowed on non-leaf (66)' visible in log, access log shows that all subentries such as indexes were deleted.
After the start/restart, error log contained message 'Detected Disorderly Shutdown last time Directory Server was running, recovering database.'
The ldbm entry for a backend and a mapping tree entry to a suffix were present in the directory, the suffix was listed as a naming context.
Version-Release number of selected component (if applicable):
389-ds-base-1.3.1.6-25
Steps to Reproduce:
See description.
Actual results:
The entries belonging to the backend and suffix are not deleted from the directory.
Expected results:
The backend is removed successfully and the database and suffix entries are removed as well, without any backend database errors or inconsistency.
Can the exact reproducible steps be provided? I ran the subtree stress test and it says there are failures, but looking through the report(which has over 500k lines) I do not see any test failures. So I don't know what to look for or how to reproduce the exact issue you are reporting. Can you tell me at least which test in the suite is failing?
I am unable to reproduce this problem.
Perhaps there was some issue with my environment when I filled this bugzilla.
All I can remember is that for some reason the backend had been indexed and when DelSuffix was called at the end of the test case (03_02) this function failed because of it and left the directory in inconsistent state.
Comment 5Sankar Ramalingam
2014-07-22 12:33:42 UTC
We need to wait till we complete Longduration and Stress executions for RHEL6.6 to make sure this problem doesn't exist anymore. Milan, you can skip this bug for time being.
Comment 6Sankar Ramalingam
2014-08-11 17:46:24 UTC
This can be marked as closed since its related to environment. If the same appears when running RHEL71 stress testing, we will re-open it.