Description of problem:

can probably be ignored as MODRDN succeeds, but trace of "urp_fixup_add_cenotaph - failed to add cenotaph, err= 68"
the errors log file can be filled with thois message.

duplicated from upstream ticket number 49623
https://pagure.io/389-ds-base/issue/49623

"
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.
"

pls comment from Ludwig K. / lkrispen
"
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
"


Version-Release number of selected component (if applicable):

RHEL-7.6 with 389-ds-base-1.3.8.4-25.1.el7_6.x86_64
trying to reproduce on RHEL-7.7 with 389-ds-base-1.3.9.1-10.el7


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: