Ticket #47649 - Server hangs in cos_cache when adding a user entry
Bug description: cos_dn_defs_cb reads cosDefinition and sets up the cos
Definition part of cos cache. In the function, when processing
cosAttribute, cosTargetTree and cosTemlpateDn are missing, it sets the
parent dn of the cos definition dn. This parent setting is needed only
when the 2 attributes are completely missing from the cos definition.
But if the attributes are located below cosAttribute (see the Example
cos definition), in addition to "cn=cosTemplates,ou=people,dc=example,
dc=com", the parent of "cn=generatePostalCode,ou=People,dc=example,dc=com"
is added to the cos cache as cosTemplateDn.
Example cos definition:
dn: cn=generatePostalCode,ou=People,dc=example,dc=com
description: generate postalCode attr based on location
objectClass: top
objectClass: ldapsubentry
objectClass: cossuperdefinition
objectClass: cosClassicDefinition
cosAttribute: postalCode
costemplatedn: cn=cosTemplates,ou=people,dc=example,dc=com
cosSpecifier: l
cn: generatePostalCode
The mistakenly added cosTemplatedDn makes adding an entry under ou=People
notify recreating the cos cache. The notification needs to be outside of
backend transaction since it causes a deadlock with the cos_cache_wait_
on_change thread which cannot read the DB due to the transaction but holds
the lock that the notifier thread is waiting for.
Fix description: The parent of the cos definition dn is set to the
cosTargetTree and the cosTemlpateDn, only when the attributes are
completely missing.
https://fedorahosted.org/389/ticket/47649
Reviewed by rmeggins@redhat.com (Thank you, Rich!!)
(cherry picked from commit 1e52401d3abd0377f55676f4a1508a02aaa7f955)
(cherry picked from commit 01c0794cde7eb91a1a4e477a0286533df4a4ae38)
(cherry picked from commit 1ebad4bd50fb1483998a32b5d3e232e89aeda0f7)