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 42abece92028193530296b5d96a6cb5261d9aa61 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 3108793c15697f6977bbfd85d5857aaa9e0aa4d9 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 ff7fb870fb0034857b855d2c9e769cdf00237aad Author: Rich Megginson rmeggins@redhat.com Date: Tue Jul 9 11:38:39 2013 -0600 8486837..dace0f1 master -> master commit dace0f15c0b19efbd6af3ef2d1a8f7992b90c140 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 b61143cc79cb5c3e23f403c4980f8a03ab7426c0 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 03a67b1432bbafe5eb7a82a8afd0832f220c229b Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
389-ds-base-1.3.0 commit 877fee5b6228faf471eefed9a073dff13074b224 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 10:49:18 2013 -0600
389-ds-base-1.2.11 commit 89a98eb66264718e3d7431a4cda92afe08371a84 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)