A race condition bug exists in the listener module initialization code that can cause modules to fail initialization even when they should succeed. During listener module initialization, the listener: * Searches for all LDAP objects matching the module's filter * Iterates through each object to process it * If an object is not found in cache, performs an individual LDAP search When an individual LDAP search returns LDAP_NO_SUCH_OBJECT (typically due to the object being deleted between steps 1 and 2), the code correctly ignores this error and continues processing. However, if LDAP_NO_SUCH_OBJECT occurs on the final iteration of the loop, the function's return value remains set to LDAP_NO_SUCH_OBJECT (error code 32). The calling function interprets this as an initialization failure and marks the module as "not ready," preventing it from processing any future events. This only happens with a very broad filter configured with the listener module (e.g. "objectClass=*" and the creation and deletion of a objects during the listener module initialization phase.
Th object being not found is a UDM settings/lock (objectClass=lock), which is created during creation or modification of objects, and then immediately removed. That's why it's not present anymore in the result list.
Fixed in version 16.2.1 of the UDM listener. Explicitly set the listener return code to LDAP_SUCCESS when LDAP_NO_SUCH_OBJECT is encountered.
* yaml: OK * changelog: OK * tests: OK
<https://errata.software-univention.de/#/?erratum=5.2x181>