#49623 cenotaph errors on modrdn operations
Closed: wontfix 4 years ago by vashirov. Opened 6 years ago by mreynolds.

Issue Description

Doing a modrdn (new superior) on a standalone plain instance (no replication setup) I see:

[23/Mar/2018:08:34:17.112762032 -0400] - ERR - conn=11 op=11 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21

I see the same error if I move it back and forth between subtrees.

If I enable replication, and delete an entry then recreate it, and do a modrdn back and forth (twice) between two subtrees I see:

[23/Mar/2018:08:39:45.077620637 -0400] - ERR - conn=11 op=75 csn=5ab4f591000000030000 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 68

--> This one is a little trickier to reproduce. It requires deleting and readding the same entry and moving it back a forth a few times, but eventually you will get the error above.

Package Version and Platform

389-ds-base-1.4.0.6 - I have not tried 1.3.7 but I suspect it is the same.


Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.3.7.0 (was: 0.0 NEEDS_TRIAGE)

6 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.2 (was: 1.3.7.0)

4 years ago

Ok, I reproduced this again. The problem is that the dn of the cenotaph is built by creatin a new rdn of

 nsuniqueid=nnnnn-nnnnn-nnnnn-nnnnn+<old rdn>

If the entry is moved back and forth between subtrees, when it is moved the second time from the same subtree will generate a dn which already exists and so the new cenotaph cannot be added.
The original MODRDN succeeds, so only a potential use in conflict resolution could be an issue, but in a usual deployment it should have no effect other than the message in theerror log

this ticket 49623 needs to be linked to the Red Hat bug report 1762901
https://bugzilla.redhat.com/1762901

Metadata Update from @vashirov:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 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/2682

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)

3 years ago

Login to comment on this ticket.

Metadata