Bug 1444947

Summary: Deadlock between topology and schema-compat plugins
Product: Red Hat Enterprise Linux 7 Reporter: Petr Vobornik <pvoborni>
Component: ipaAssignee: Pavel Picka <ppicka>
Status: CLOSED ERRATA QA Contact: Pavel Picka <ppicka>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.4CC: ksiddiqu, mbasti, nsoman, pvoborni, rcritten, slaznick, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.5.0-9.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 09:50:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output none

Description Petr Vobornik 2017-04-24 15:15:22 UTC 
Cloned from upstream: https://pagure.io/freeipa/issue/6821

On Fedora 25
389-ds-base-1.3.5.15-1
freeipa 4.5.git build

The deadlock occurs 20sec after DS startup. A schedule event (topology plugin) creates a 'iparepltoposegment' entry (thread 36):
  ADD "cn=<vm-1>-to-<vm-2>,cn=domain,cn=topology,cn=ipa,cn=etc,<suffix>"


at the same time a new index (numsubordinates) on IPACA is created (thread 35):
   cn=numsubordinates,cn=index,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
   objectclass: top
   objectclass: nsIndex
   cn: numsubordinates
   nsSystemIndex: true
   nsIndexType: pres


The problem is that thread 36 hold DB locks before attempting to acquire schema-compat map lock (to find groups owning the index).

At the same time thread 35 that holds schema-compat map lock does an internal search to retrieve groups owning the segment.
  -b "cn=groups,cn=accounts,<suffix>"  "member=cn=numsubordinates,cn=index,cn=ipaca,cn=ldbm database,cn=plugins,cn=config"


So the deadlock comes from locks taken in the opposite order.
Comment 2 Petr Vobornik 2017-04-24 15:15:40 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/6821
Comment 3 Martin Bašti 2017-04-24 15:16:45 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/0c0af8cf7adf61ef03ba1240ecbdecef7fa15275
https://pagure.io/freeipa/c/ddbbb1c58e8a4fec8129e7d1e941c54660af6a69
https://pagure.io/freeipa/c/645615958d4b0f9e6dd8a5ff2541952abb588d55
https://pagure.io/freeipa/c/68c8ddf1871efe7ef78ce153573d522aefecfdfa
ipa-4-5:
https://pagure.io/freeipa/c/4fa7718c6ad03a7cf534313d5c50d78d4863fe6e
https://pagure.io/freeipa/c/7364c1360c4e2271667f3a08d8d504b3cd813e2f
https://pagure.io/freeipa/c/e691877c24e722d4fc91fed34cd31cc102879c1a
https://pagure.io/freeipa/c/efe096040aefdeea37afcf2671506982d8522f47
Comment 7 Standa Laznicka 2017-06-07 05:51:57 UTC 
This is supposed to be sanity-tested - install and see if it works.

Also, you should test that ipa-compat-manage now behaves the same for both root and non-root users regarding enabling, disabling and checking status of the compat plugin.
Comment 8 Pavel Picka 2017-06-08 12:00:02 UTC 
Created attachment 1286128 [details]
output

Verified on ipa-server-4.5.0-14.el7.x86_64
Comment 9 errata-xmlrpc 2017-08-01 09:50:15 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2304