#47392 ldbm errors when adding/modifying/deleting entries
Closed: wontfix None Opened 9 years ago 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).

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

5 years ago

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)

2 years ago

Login to comment on this ticket.

Metadata