#47392 ldbm errors when adding/modifying/deleting entries
Closed: wontfix Opened by nkinder.

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata