Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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.

Upstream ticket:
https://pagure.io/freeipa/issue/6821

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

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.

Created attachment 1286128 [details]
output

Verified on ipa-server-4.5.0-14.el7.x86_64

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