You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When SSSD has been started while offline everything works nicely but when going back online things involving id queries start to cause noticeable lags (e.g., when opening a new terminal). These lags correspond in lenght to dns_resolver_timeout value. Queries for id information not in cache fail.
I have verified by monitoring logs and network traffic that when SSSD write to log that it is resolving a data provider (an LDAP server in this case) no packets are actually ever sent over the network. After the time period defined in dns_resolver_timeout has passed, SSSD concludes that the data provider is unreachable. It could be noted that if one uses ldapsearch in a terminal while SSSD is seemingly trying to resolve the host name, ldapsearch returns expected results immediately.
So it would seem that either SSSD never communicates with c-ares correctly or for some reason c-ares fails to do the actual query.
I have access to a private (customer) network where I can reproduce this so I can provide more logs in private if needed.
Tested with sssd-1.1.91 and c-ares-1.6.0 on RHEL5.5.
After lots of debugging it turns out that this is because the propritary Cisco VPN client (using a kernel module) break inotify, thus SSSD was trying to contact the old name server.
So this is a Cisco VPN client issue, not an SSSD problem.
As myllynen says, we've determined that this is a bug in the Cisco VPN client, not SSSD. I have opened ticket #484 to provide a workaround in the future for this and other tainted kernel modules.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/480
When SSSD has been started while offline everything works nicely but when going back online things involving id queries start to cause noticeable lags (e.g., when opening a new terminal). These lags correspond in lenght to dns_resolver_timeout value. Queries for id information not in cache fail.
I have verified by monitoring logs and network traffic that when SSSD write to log that it is resolving a data provider (an LDAP server in this case) no packets are actually ever sent over the network. After the time period defined in dns_resolver_timeout has passed, SSSD concludes that the data provider is unreachable. It could be noted that if one uses ldapsearch in a terminal while SSSD is seemingly trying to resolve the host name, ldapsearch returns expected results immediately.
So it would seem that either SSSD never communicates with c-ares correctly or for some reason c-ares fails to do the actual query.
I have access to a private (customer) network where I can reproduce this so I can provide more logs in private if needed.
Tested with sssd-1.1.91 and c-ares-1.6.0 on RHEL5.5.
Comments
Comment from myllynen at 2010-05-14 17:32:17
After lots of debugging it turns out that this is because the propritary Cisco VPN client (using a kernel module) break inotify, thus SSSD was trying to contact the old name server.
So this is a Cisco VPN client issue, not an SSSD problem.
Comment from sgallagh at 2010-05-14 17:36:59
As myllynen says, we've determined that this is a bug in the Cisco VPN client, not SSSD. I have opened ticket #484 to provide a workaround in the future for this and other tainted kernel modules.
resolution: => worksforme
status: new => closed
Comment from dpal at 2012-01-19 02:12:37
Fields changed
rhbz: => 0
Comment from simo at 2012-03-08 15:25:44
Fields changed
milestone: NEEDS_TRIAGE => void
Comment from myllynen at 2017-02-24 14:54:13
Metadata Update from @myllynen:
The text was updated successfully, but these errors were encountered: