#47392 ldbm errors when adding/modifying/deleting entries
Closed: Fixed None Opened 6 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

2 years ago

Login to comment on this ticket.

Metadata