Description of problem: Potential deadlocks can occur when tasks are added to the Directory Server. Where the task itself creates new thread and makes database updates, and the task add operation also triggers post plugins to fire off. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Install FreeIPA server: # ipa-server-install 2. Authenticate as admin: # kinit admin 3. Add a hostgroup: # ipa hostgroup-add --desc="Web Servers" webservers 4. Add a host: # ipa host-add web1.example.com --force 5. Add an automember rule: # ipa automember-add --type=hostgroup webservers # ipa automember-add-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers 6. Try to rebuild membership: # cat rebuild.ldif dn: cn=rt,cn=automember rebuild membership,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: rt basedn: cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com filter: (fqdn=*) scope: sub 7. ldapmodify -x -D 'cn=directory manager' -w password -f rebuild.ldif adding new entry "cn=rt,cn=automember rebuild membership,cn=tasks,cn=config" Actual results: The ldapmodify in step 7 hangs Expected results: ldapmodify does not hang the Directory Server
Does it apply for both 7.0 and 6.4? We did not update slapi-nis in 6.4... Looks like duplicate of Bug 1007451.
Moving to the right component. But I still think that this is not an issue for RHEL-6.5. If this is the case, I would kindly ask reporter or asignee to close it.
Given that the backtraces showed that this was an interaction between slapi-nis's internal locking and the transaction locks which we're using in later releases, we're now confident that this bug doesn't affect 6.x releases. Marking as closed->next release, because we're fixing it there.