#49300 Duplicate entryUSN numbers for different LDAP entries in the same backend
Closed: fixed 16 days ago by spichugi. Opened 3 years ago by pj101.

Issue Description

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.

Steps to reproduce

  1. Probably heavy large group modifications with memberOf and entryUSN plugins enabled
  2. Check dbscan -r -f entryusn.db
  3. To find all duplicate entries:
    dbscan -r -f entryusn.db | tail -n +3 | grep -B 1 '[0-9]+ [0-9]'

Actual results

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

Expected results

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

3 years ago

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

Also, the issue (I think it is the same issue) possible to reproduce with TET - subtreeRenamesRunIt - subtree_31 test case.

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

2 years ago

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

a year ago

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1851973

a month ago

Metadata Update from @spichugi:
- Issue assigned to spichugi

23 days ago

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)

16 days ago

Login to comment on this ticket.

Metadata
Attachments 2
Attached 3 years ago View Comment
Attached 3 years ago View Comment