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.
Bug 736431 has been fixed as part of ticket #2: https://fedorahosted.org/389/ticket/2
Added initial screened field value.
Metadata Update from @nhosoi: - Issue assigned to rmeggins - Issue set to the milestone: 1.2.10
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Duplicate)
Login to comment on this ticket.