Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 972976
Description of problem: The issue I am encountering are the following errors when an entry is being added to the directory or deleted from the directory ? it seems an operations error err=1 corresponds to a failure in the backend ldbm (see log snippets below). Version-Release number of selected component (if applicable): 389-ds-base.x86_64 1.2.11.15-14.el6_4 @rhel-x86_64-server-6 Linux 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 6.4 (Santiago) How reproducible: Consistently reproducible. Steps to Reproduce: I can reproduce these errors consistently by running a JMeter add/delete loop test to add and delete entries (see the attached testplan_. It always transpires that some entries will fail to add or delete and will throw an operations error err=1 and a corresponding ldbm error. Actual results: err=1 and ldbm errors; entry fails to add or delete. Expected results: Entries should be added and deleted successfully. Additional info: The DNA plugin is active on the server. When sent a uidNumber of 999 or gidNumber of 999, it will generate a new POSIX uid/gid. The servers are in a replicated environment (2 MMR masters and 3 replicas). The error seems to occur regardless of whether the DNA plugin is used or not (i.e. when sending a non-POSIX entry vs. a POSIX entry to LDAP).
see also https://fedorahosted.org/389/ticket/47418
The errors look like this: {{{ [10/Jun/2013:14:46:43 -0700] - ldbm_back_delete: modify_switch_entries failed [10/Jun/2013:14:50:59 -0700] - ldbm_back_modify: modify_switch_entries failed [10/Jun/2013:14:50:59 -0700] - ldbm_back_add: modify_switch_entries failed }}}
0001-Ticket-47392-ldbm-errors-when-adding-modifying-delet.patch 0001-Ticket-47392-ldbm-errors-when-adding-modifying-delet.patch
Looks good. Is 1.3.x also affected, the ruv context is already in the retry loop ? But the hardening of the ruv update code not to go backwards could still be useful
Replying to [comment:5 lkrispen]:
Looks good. Is 1.3.x also affected, the ruv context is already in the retry loop ?
I've done all of my work so far against 1.2.11 - will have to see what of this is applicable for 1.3.1
But the hardening of the ruv update code not to go backwards could still be useful
Yes - parts of this still apply e.g. a preop update will have a later CSN than the "main" op and the main op should not cause the csn in the ruv to go backwards
cd5bfad..42abece 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 42abece Author: Rich Megginson rmeggins@redhat.com Date: Tue Jul 9 11:38:39 2013 -0600 49ed254..3108793 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit 3108793 Author: Rich Megginson rmeggins@redhat.com Date: Tue Jul 9 11:38:39 2013 -0600 ad8f908..ff7fb87 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit ff7fb87 Author: Rich Megginson rmeggins@redhat.com Date: Tue Jul 9 11:38:39 2013 -0600 8486837..dace0f1 master -> master commit dace0f1 Author: Rich Megginson rmeggins@redhat.com Date: Tue Jul 9 11:38:39 2013 -0600
To ssh://git.fedorahosted.org/git/389/ds.git 50ba5a0..ba70aac master -> master commit b61143c Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
fix coverity 11895 - null deref - caused by fix to ticket 47392
389-ds-base-1.3.1 commit 03a67b1 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
389-ds-base-1.3.0 commit 877fee5 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
389-ds-base-1.2.11 commit 89a98eb Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: 1.2.11.22
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/729
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.