Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-6020: LDAP Proxy stops running at various intervals

12 April,16 at 10:57 AM

Applies to:

All versions of LDAP Proxy

Problem:

LDAP Proxy appears to stop working at various intervals. Messages similar to the following can be observed in the system logs:

Apr 8 09:28:14 proxysrv01 slapd[1058]: [ID 702911 auth.warning] WARNING: Failed to send message: File operation error, MsgType: 909

..

Apr 8 09:28:17 proxysrv01 adclient[12798]: [ID 702911 auth.warning] WARN <fd:37 slapd(1058)> Failed to send message: File operation error, MsgType: 909


It may also be observed that slapd has a large amount of file descriptors in use and that the failures coincide with file descriptors reaching a particular limit (ie. 256)


Cause:

This behavior is not caused by LDAP Proxy itself, but by a client utilizing the service. As an example, we are able to reproduce this issue with a web application utilizing LDAP Proxy with a TTL on auth set to ~15seconds. This causes a large number of file descriptors(FDs) and left-open network sockets.  Normally, this is not a problem as slapd will gradually close these sockets as they are idle for a specific amount of time, however in this scenario, slapd cannot keep up with the amount of sockets being opened and left open, so the limit is quickly reached and, thus, the behavior is observed.


Workaround/Resolution:

Two options:

1) Modify /etc/centrifydc/openldap/slapd.conf to add/modify the following parameter:

idletimeout 16

This will have the effect of having slapd check for idle sockets every 4 (16/4) seconds and close sockets that have been idle for longer than 16 seconds. This value may be modified as befits your specific scenario.

OR

2) Adjust the client application to have a lower TTL. Using the example from above, lowering our web application's authentication TTL to approximately 5seconds alleviated the issue. This option may vary significantly, depending on the client type.

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.