#33 parent tombstone entry could be reaped even if its child tombstone entries still exist
Closed: wontfix None Opened 12 years ago by mkosek.

https://bugzilla.redhat.com/show_bug.cgi?id=736431

Description of problem:
Anthony Messina 2011-09-05 23:18:59 EDT

Using 389-ds-base-1.2.9.9-1.fc15.x86_64

I see the following when backing up the db:
[05/Sep/2011:03:30:11 -0500] ldif2dbm - _get_and_add_parent_rdns: Failed to
position at ID 29
[05/Sep/2011:03:30:11 -0500] - ldbm2ldif: Failed to get dn of ID 29
[05/Sep/2011:03:30:11 -0500] - export userRoot: Processed 359 entries (100%).
[05/Sep/2011:03:30:11 -0500] - All database threads now stopped
[05/Sep/2011:03:30:11 -0500] - export NetscapeRoot: Processed 109 entries
(100%).
[05/Sep/2011:03:30:11 -0500] - All database threads now stopped
        389-Directory/1.2.9.9 B2011.244.2041


And the following later on:
[05/Sep/2011:14:11:59 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:14:11:59 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"
[05/Sep/2011:22:13:08 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:22:13:08 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"
[05/Sep/2011:22:13:45 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:22:13:45 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"

[reply] [-]
Private
Comment 5 Noriko Hosoi 2011-09-06 12:49:13 EDT

Hi Anthony,
Could it be possible to post the output from these command lines?
dbscan -f /path/to/db/userRoot/id2entry.db4 -K 29
dbscan -f /path/to/db/userRoot/id2entry.db4 -K 30
Thanks,
--noriko

[reply] [-]
Private
Comment 6 Anthony Messina 2011-09-06 13:36:10 EDT

Sure, they both come from entries that were deleted.  The first one is gone
from the DB.  The second doesn't show up during an ldapsearch, but is avaiable
via the command below:

# dbscan -f /var/lib/dirsrv/slapd-ds/db/userRoot/id2entry.db4 -K 29
Can't set cursor to returned item: DB_NOTFOUND: No matching key/data pair found


# dbscan -f /var/lib/dirsrv/slapd-ds/db/userRoot/id2entry.db4 -K 30
id 30
        rdn:
nsuniqueid=de6aa638-282011df-a269e3fe-897a001a,uid=aae5b81917538f54cabd7e
         7d290db106
        nsUniqueId: de6aa638-282011df-a269e3fe-897a001a

<entry snipped>

[reply] [-]
Private
Comment 7 Noriko Hosoi 2011-09-06 18:53:35 EDT

Thanks, Anthony.  I tried to duplicate your problem, but so far no luck.

It looks you have some deleted entries which are turned to tombstone entries
once (entry 29 and 30).  Then, some of them are reaped (entry 29).  I wonder if
entry 29 could have been a parent of entry 30?  (I don't think a parent can be
deleted prior to its child, so I'm not sure how it could happen if it is the
case...)  But this could be just my imagination.  I guess we need more detailed
data to investigate the problem.

Do you happen to have steps to reproduce the problem?

[reply] [-]
Private
Comment 8 Anthony Messina 2011-09-07 05:38:35 EDT

(In reply to comment #7)
> Thanks, Anthony.  I tried to duplicate your problem, but so far no luck.
>
> It looks you have some deleted entries which are turned to tombstone entries
> once (entry 29 and 30).  Then, some of them are reaped (entry 29).  I wonder
if
> entry 29 could have been a parent of entry 30?  (I don't think a parent can
be
> deleted prior to its child, so I'm not sure how it could happen if it is the
> case...)  But this could be just my imagination.  I guess we need more
detailed
> data to investigate the problem.
>
> Do you happen to have steps to reproduce the problem?

I believe you are right when you say that 29 was a parent of 30.  In fact, the
30 entry I have was deleted at the same time as its parent (29) via the
389-console.

It would have had the following structure:
uid=aae5b81917538f54cabd7e7d290db106,cn=user1,ou=personal,ou=contacts,ou=messin
et.com,ou=eGW,dc=messinet,dc=com

and cn=user1,ou=personal,ou=contacts,ou=messinet.com,ou=eGW,dc=messinet,dc=com
was the entry I deleted via 389-console.

Added initial screened field value.

Metadata Update from @nhosoi:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.10

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

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: Duplicate)

3 years ago

Login to comment on this ticket.

Metadata