A LDAP listener is a dedicated process that periodically searches for changes to users and groups on the LDAP server. This feature based on your LDAP persistent search is rare to be stopped. Even more rare for the "stop listener" to hang. As rare as hens' teeth, the LDAP listener can fail to shutdown. Here is a quick workaround to make LDAP Listener work again.
You would like to stop the listener if you are performing changes on the LDAP server or LDAP OU Definitions. Normally, when stopped, the listener will go to Inactive. Very rarely, when stopping the listener, it changes to "Active (Shutting down...)" indefinitely.
Below are the main steps to force stop your listener:
There are six (6) steps to ensure the LDAP server stops:
1. Stop Listeners on all LDAP Servers. If using mid-server, please also stop the mid-server.
2. Confirm that the "LDAP monitor" does not show the ldap listener as running.
3. If LDAP listener is still running, create a new Scheduled job on demand and execute.
4. Delete all entries from sys_status_list.do with 'name' starting with "glide.ldap.listener"
5. Confirm that the "LDAP monitor" list does not show the ldap listener as running.
6. If a mid-server is used, start the mid-server. Start the LDAP listeners.
1. Stop Listeners on all LDAP Servers. If using mid-server, please also stop the mid-server.
To avoid side effects with other listeners running, please ensure to use the 'Stop Listener' on all the active LDAP Server. Please note that stopping the listeners will not affect the user authentication for existing users. If using mid-server, you will need to stop the mid-server.
Here is how it looks like to open each LDAP server entry and click on "Stop Listener":
2. Confirm that the "LDAP monitor" does not show the ldap listener as running.
Go to the LDAP server monitor page and validate the LDAP listeners are stopped. You will know if they have stopped because the status will be 'Inactive'
3. If LDAP listener is still running, create a new Scheduled job on demand and execute.
This is an advanced task. You can use a background script if you have access to them. Otherwise, create a scheduled job.
On this example, I will stop the listener for LDAP Server with sys_id = bdca2a7d4f8c92002f97fdb28110c786.
Here is an example of the job to create.
Scheduled Job | ||
Name | = | stop Ldap Listener |
Active | = | checked |
Run | = | On Demand |
Trigger type | = | On Demand |
Script =
stopLdapListener("bdca2a7d4f8c92002f97fdb28110c786");
function stopLdapListener (ldap_server_sys_id) {
var ldapConfig = new GlideLDAPConfig().get(ldap_server_sys_id);
ldapConfig.stopListener();
gs.log('LDAP listener for: ' + ldapConfig.getName() + ' (' + ldap_server_sys_id + ') has been stopped.', "stopLdapListener")
}
The logs should show the following entries:
4. Delete all entries from sys_status_list.do with 'name' starting with "glide.ldap.listener"
Open <instance>/sys_status_list.do?sysparm_query=nameSTARTSWITHglide.ldap.listener and delete all the entries. They will get recreated once the listeners are started.
5. Confirm that the "LDAP monitor" list does not show the ldap listener as running.
Go to the LDAP monitor page and validate the listener statuses. They should be 'Inactive'
6. If a mid-server is used, start the mid-server. Start the LDAP listeners.
Finally, if you are using mid-server, then start the mid-server.
Then for each LDAP Server active record with a LDAP listener you want to start, click 'Start Listener' (or 'Stop Listener' if available first).
To validate if they have started correctly, go to the LDAP monitor page and validate the listener statuses. They should be 'Active' for the ones started.
In a nutshell, there is a few advanced steps to perform if you need to stop the LDAP listener that is too temperamental to shutdown. Pay additional attention if you are using mid-servers as they also need to be restarted.
I've tested this on Fuji with Chrome as browser.
More information found here:
