389-ds-base

#376 cannot delete tombstone entries
Closed: wontfix Opened by rmeggins.

Closed: wontfix
Reopen Issue

An attempt to delete a tombstone entry gives err=32 - no such entry:

17/May/2012:01:41:35 +0000] conn=947 fd=80 slot=80 SSL connection from
::1 to ::1
[17/May/2012:01:41:35 +0000] conn=947 SSL 256-bit AES
[17/May/2012:01:41:35 +0000] conn=947 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[17/May/2012:01:41:35 +0000] conn=947 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[17/May/2012:01:41:35 +0000] conn=947 op=1 DEL
dn="nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=username,ou=people,dc=example,dc=com"
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=2 UNBIND
[17/May/2012:01:41:35 +0000] conn=947 op=2 fd=80 closed - U1

Note there are two result lines - this is bad.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=830342

Before I forget, here was the latest status...

If a tombstone entry is in the cache, you can delete it, but when it's not, you can not delete the tombstone(error 32).

Stack trace:

ldbm_entryrdn.c:3245: _entryrdn_get_elem returns -30988

0 _entryrdn_index_read (be=0xfef0a0, cursor=0x108ea60, srdn=0x7f04a25f3700, elem=0x7f04a25f3740, parentelem=0x0, childelems=0x0, flags=0, db_txn=0x0) at ../ds/ldap/servers/slapd/back-ldbm/ldbm_entryrdn.c:3247

1 entryrdn_index_read_ext (be=0xfef0a0, sdn=0x7f04680008c0, id=0x7f04a25f380c, flags=0, txn=0x7f04a25f3b30) at ../ds/ldap/servers/slapd/back-ldbm/ldbm_entryrdn.c:439

2 dn2entry_ext (be=0xfef0a0, sdn=0x7f04680008c0, txn=0x7f04a25f3b30, flags=0, err=0x7f04a25f38a8) at ../ds/ldap/servers/slapd/back-ldbm/dn2entry.c:92

3 find_entry_internal_dn (pb=0x11c8660, be=0xfef0a0, sdn=0x7f04680008c0, lock=1, txn=0x7f04a25f3b30, flags=0) at ../ds/ldap/servers/slapd/back-ldbm/findentry.c:130

4 find_entry_internal (pb=0x11c8660, be=0xfef0a0, addr=0x11c89e8, lock=1, txn=0x7f04a25f3b30, flags=0) at ../ds/ldap/servers/slapd/back-ldbm/findentry.c:293

5 find_entry2modify (pb=0x11c8660, be=0xfef0a0, addr=0x11c89e8, txn=0x7f04a25f3b30) at ../ds/ldap/servers/slapd/back-ldbm/findentry.c:324

6 ldbm_back_delete (pb=0x11c8660) at ../ds/ldap/servers/slapd/back-ldbm/ldbm_delete.c:185

The problem why it fails is that entryrdn_index_read_ext() strips off the tombstone flag so it ignores the tombstone rdns:

dn2entry.c:92  *err = entryrdn_index_read_ext(be, sdn, &id, flags & TOMBSTONE_INCLUDED, txn);

This was apparently stripped off to improve performance. Needs more investigation...

set default ticket origin to Community

Added initial screened field value.

Manual tombstone deletion is not recommended/supported.
. As described in comment 6, the operation is only allowed when the tombstone entry is in entry cache.
. Even if a tombstone entry is deleted on a master, the operation is not replicated to the consumers.
. The same symptom is observed on RHDS8.2, as well.
. We strongly recommend to use tombstone reap to clean up tombstone entries. A doc bug was filed for that: Bug 974695 - Adding tombstone entry and how to delete it to Admin Guide.

Metadata Update from @nkinder:
- Issue assigned to mreynolds
- Issue set to the milestone: N/A

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/376

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: Invalid)
Metadata
None
None
None
Normal
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.