The version was 389-ds-base-1.3.3.9-1 (F21).
A write operation (like a DEL) can update nsuniqueid index. in betxn_postop when it tries to update the changelog/ruv, it tries to update the replica agreements and so acquire the RA locks.
If at the same time, the replica agreement is started, it triggers an internal search to retrieve the current ruv. It does internal search using nsuniqueid and so while it is holding the RA lock it accesses the nsuniqueid index.
Could be related to fix: Ticket 47368 - IPA server dirsrv RUV entry data excluded from replication
How to reproduce: I reproduced it several times on VM F21 with ticket47787_test.py
Here is a first analyze of the deadlock:
{{{ Thread 23 (Thread 0x7f15c6ffd700 (LWP 7007)):
24 dd=21 locks held 0 write locks 0 pid/thread 6986/7F15C6FFD700 flags 0 priority 100 24 dd=21 locks held 0 write locks 0 pid/thread 6986/139731509696256 flags 0 priority 100 24 READ 1 WAIT userRoot/nsuniqueid.db page 1
Thread 30 (Thread 0x7f15ceffd700 (LWP 7000)):
800000a8 dd= 1 locks held 20 write locks 13 pid/thread 6986/7F15CEFFD700 flags 0 priority 100 800000a8 dd= 1 locks held 20 write locks 13 pid/thread 6986/139731643913984 flags 0 priority 100 800000a8 WRITE 1 HELD /var/lib/dirsrv/slapd-master_2/changelogdb/f502a608-efe811e4-908cc50a-b5be7e58_55434ed8000000010000.db page 3 800000a8 WRITE 1 HELD userRoot/numsubordinates.db page 1 800000a8 WRITE 1 HELD userRoot/id2entry.db page 2 800000a8 WRITE 1 HELD userRoot/nscpEntryDN.db page 1 800000a8 WRITE 1 HELD userRoot/nsTombstoneCSN.db page 1 800000a8 WRITE 9 HELD userRoot/entryrdn.db page 1 800000a8 WRITE 4 HELD userRoot/ancestorid.db page 1 800000a8 READ 2 HELD userRoot/ancestorid.db page 1 800000a8 READ 10 HELD userRoot/entryrdn.db page 1 800000a8 WRITE 3 HELD userRoot/parentid.db page 1 800000a8 READ 1 HELD userRoot/parentid.db page 1 800000a8 WRITE 3 HELD userRoot/nsuniqueid.db page 1 800000a8 WRITE 28 HELD userRoot/cn.db page 1 800000a8 READ 14 HELD userRoot/cn.db page 1 800000a8 WRITE 28 HELD userRoot/sn.db page 1 800000a8 READ 14 HELD userRoot/sn.db page 1 800000a8 WRITE 5 HELD userRoot/objectclass.db page 1 800000a8 READ 2 HELD userRoot/objectclass.db page 1 800000a8 WRITE 1 HELD userRoot/id2entry.db page 3 800000a8 READ 5 HELD userRoot/nsuniqueid.db page 1
}}}
attachment 48179.tar.gz
I also ran into this deadlock while investigating ticket 47788.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1243950
attachment 0001-Ticket-48179-Starting-a-replica-agreement-can-lead-t.patch
Looks good!
An extremely minor issue. We don't need this cast any more! ;)
705 (Slapi_DN *)repl_sdn,
I rmeoved that cast. Thanks for the review Noriko!
f5d2445..eb3086d master -> master commit eb3086dcb0c56a23d6cee00a12f38b2584fe59a2 Author: Mark Reynolds mreynolds@redhat.com Date: Fri Jul 17 15:08:00 2015 -0400
8600a5e..23a3ff6 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 23a3ff6082cba3eb749401eff44942b16dc30538
Metadata Update from @tbordaz: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.4.2
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/1510
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)