On Mon, Aug 27, 2012 at 11:39:24AM +0200, Olaf Gellert wrote:
we do see some timeouts when sssd tries to bind to the LDAP
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [be_resolve_server_done]
(4): Found address for server xxx1.domain.de: [10.11.12.13] TTL 21600
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [fo_set_port_status] (4):
Marking port 636 of server 'xxx1.domain.de' as 'working'
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [set_server_common_status]
(4): Marking server 'xxx1.domain.de' as 'working'
(Mon Aug 27 10:35:54 2012) [sssd[be[LDAP]]] [simple_bind_send] (4):
Executing simple bind as: uid=abcdefg,ou=People,o=ldap,o=root
(Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_run_offline_cb] (3):
Going offline. Running callbacks.
(Mon Aug 27 10:35:59 2012) [sssd[be[LDAP]]] [be_pam_handler_callback]
(4): Backend returned: (1, 9, <NULL>) [Provider is Offline
(Authentication service cannot retrieve authentication info)]
In this case sssd seems to not ask the second ldap server?
We ser the "ldap_search_timeout" option to 120 seconds (default
is 6 seconds), but this does change the behaviour.
We are running sssd 1.5.1 (as distributed with CentOS 5.X).
Looking at all the different ldap timeout values, I guess that
"ldap_network_timeout" is not the right thing (because network
connect does work), could "ldap_opt_timeout" provide some solution
(as I do not really understand what it does)?
as you discovered, the ldap bind timeout is currently hardcoded to 5
seconds. I think we wanted to make this setting configurable when we
were working on making the bind asychronous, but we cancelled that
Maybe it would be beneficial to either reuse ldap_opt_timeout for the
bind timeout value or introduce a new timeout. I filed
to track this.
I am far more concerned about the provider going offline without asking the
secondary LDAP server. I'll try to reproduce the issue locally.