[Freeipa-users] Needs help understand this timeout issue

[Troels Hansen]

Hmm, suspect its happening on the server...... thous I haven't been able to pinpoint a log entry that confirms my suspecting.

I have pinpointed the timeout to happen after 58 seconds after completely removing the SSSD cache and restaring SSSD, which leads me to think my issue is related to ldap_enumaration_search_timeout which defaults to 60.

rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja

However, I'm unable to crank it up on the server as it seems to be adjusted Down to 60 Again?

Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option ldap_enumeration_search_timeout has value 120
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400): Option ldap_enumeration_search_timeout has value 60

LDAP seems speedy enough, not timeouts while querying it manually while a client is doing a user lookup.

----- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI] dsullivan2 at bsd.uchicago.edu wrote:

> 
> If the timeout is occurring on the server, I would start by increasing one or
> both of these values:
> 
> ldap_opt_timeout
> ldap_search_timeout
> 
> If that doesn’t work I’d take look to see if the 389 server is under high load
> when you are performing this operation.  The easiest way I have found to do
> this is to just execute an LDAP query directly against the IPA server when you
> are performing an id lookup, for example:
> 
> ldapsearch -D "cn=Directory Manager" -w <pw> -s base -b "cn=config"
> "(objectclass=*)”
> 
> If the LDAP server is not responsive you probably need to increase the number of
> worker threads for 389ds.  Also, you might want to disable referrals, check out
> the man pages for this;
> 
> ldap_referrals = false
> 
> Also, FWIW, if you crank up debug logging on the sssd client, you should be able
> to see the amount of seconds of timeout assigned to the operation, and witness
> the fact that the operation is actually timing out by inspecting the logs
> themselves.  The logs can get a little verbose but the data is there.
>