According to the description of entryUSN plugin and attribute functioning (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/tracking_modifications_to_directory_entries) it should be unique for each backend (excluding entryusn=0 for imported and never changed entries). In our production environment (389ds v1.3.6.6) there are multiple entries having 2 exactly same entryUSN. Generally it's a group and a user entry that was added/deleted from that group.
for some entryUSN numbers there are two entries: =174757 9955 40108 It is always a group and a user, so it is very probable the duplicate entryUSN is generated during memberOf plugin functioning: cn=Groupe Example,ou=Par entite,ou=Groupes Globaux,ou=Groupes,dc=id,dc=polytechnique,dc=edu ... uniqueMember: uid=user1,ou=Personnel,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu ... modifyTimeStamp: 20170620133023Z modifiersName: cn=X LDAP Root entryUSN: 174757
uid=user1,ou=Personnel,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu ... memberOf: cn=Groupe Example,ou=Par entite,ou=Groupes Globaux,ou=Groupes,dc=id,dc=polytechnique,dc=edu ... modifyTimeStamp: 20170620133023Z modifiersName: cn=X LDAP Root entryUSN: 174757
entryUSN is supposed to be unique per backend according to documentation. These duplicates are not very critical since anyway the two changed entries will be found by the filter entryUSN>=n.
Frequency of occurence: we have 60 duplicate entryUSN for 10650 distinct values of entryUSN contained in entryusn.db
@pj101 Through another ticket, I may have an idea about why this occurs. I will update shortly on my findings
Metadata Update from @firstyear: - Custom field type adjusted to defect
Some additional information: lastusn;userroot at the "" is sometimes larger than the real maximum entryUSN in the index entryusn.db. It probably happens because of the duplicates in index:
ldapsearch -x -h ldap-model.polytechnique.fr -b "" -s base '(objectClass=*)' 'lastusn;userroot' dn: lastusn;userroot: 176
dbscan -r -f entryusn.db | tail =171 8681 =172 8726 =173 8960 =174 9020 =175 6597 24283
After server restart the the value of lastusn;userroot returns to the real maximum value in index: ldapsearch -x -h ldap-model.polytechnique.fr -b "" -s base '(objectClass=*)' 'lastusn;userroot' dn: lastusn;userroot: 175
I reproduced the issue quite easily, a log of my actions is attached, it shows the duplicate entryusn problem and the problem of lastusn beeing ahead
<img alt="dup-entryusn.txt" src="/389-ds-base/issue/raw/f945cba6cddcc17a2c693be341b93857ae5c19fd4bf748472748649f025bc2a0-dup-entryusn.txt" />
Also, the issue (I think it is the same issue) possible to reproduce with TET - subtreeRenamesRunIt - subtree_31 test case.
Here is a test script
<img alt="ticket49300_test.py" src="/389-ds-base/issue/raw/7fa1c75309d118d9724c63fa53ce8d5d016984b7f9aa951929be599550afb947-ticket49300_test.py" />
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.3.7.0
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.2 (was: 1.3.7.0)
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1851973
Issue linked to Bugzilla: Bug 1851973
https://pagure.io/389-ds-base/pull-request/51204
Metadata Update from @spichugi: - Issue assigned to spichugi
654d0ff..ffda491 master -> origin/master 6023396..14b0dcb 389-ds-base-1.4.2 -> 389-ds-base-1.4.2 668475a..f7f79ae 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
Metadata Update from @spichugi: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
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/2359
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: fixed)
Login to comment on this ticket.