Typically, the LDAP server runs as soon as it is loaded. However, either of two scenarios can prevent the server from running properly.
Scenario: The Server Is in a Zombie State. The LDAP server loads as long as the DHost Loaders can resolve external dependencies. However, the LDAP server doesn’t run properly until it can get a valid configuration from the two configuration objects (the LDAP Server and LDAP Group objects).
While the LDAP server is in a loaded-but-not-running (zombie) state, it periodically tries to find and read the configuration objects. If the objects are misconfigured or corrupted, the LDAP server stays in the zombie state until the server (nldap.nlm, nldap.dlm, libnldap.so, or libnldap.sl) is unloaded or taken down.
The Loaders show that the LDAP server is loaded, but no LDAP ports (389, 636) are opened by nldap.nlm (or nldap.dlm, libnldap.so, or libnldap.sl). Also, no LDAP client requests are serviced.
DSTrace messages will show the periodic attempts and the reason why the server cannot come up to the running state.
Scenario: Denial of Service . At Digital Airlines, the server is processing a very long (20 minutes or more) search operation. The search is, in effect, looking for a needle in a haystack.
During this search, Henri does one of the following:
Changes a configuration parameter and updates a configuration object.
Clicks Refresh Server Now.
Unloads the LDAP server (nldap.nlm, nldap.dlm, libnldap.so, or libnldap.sl).
Tries to take the entire server down.
The LDAP server waits until all current operations complete before applying any new update. The server also postpones new operations from running until the update is complete. This delay can cause the server to appear to stop responding to new requests until the search is done and the server can refresh itself. Or the server appears to hang during the unload.
If the search request is long but has many hits, and Henri unloads the LDAP server, it aborts the search and quickly unloads when the next hit is returned to the client. However, if the search request has only one or no hits in 20 minutes, the LDAP server isn't able to abandon the NDS® or eDirectory request in progress.
For a refresh or update, the search will not be aborted even if it has many hits to return to the client.