Hi,
I just had a weird situation: one of my servers suddenly no longer allowed me to log in (pam auth via sssd). Looking in the log for sssd, I had this message once every minute:
[sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
Also, "getent passwd" no longer showed any ldap users. Everything seemed correct, also the ldap servers, so I just restarted the sssd daemon and all was well again. Shouldn't the retry options of sssd just do that? I have this as sssd config (obfuscated a bit):
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = LDAP
[nss] filter_groups = root filter_users = root,ldap,named,avahi,haldaemon,messagebus,dbus,vcsa,ntp reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/LDAP] id_provider = ldap auth_provider = ldap access_provider = ldap ldap_access_filter = memberOf=xxxx ldap_uri = ldap://host1, ldap://host2 ldap_search_base = xxxxx ldap_tls_reqcert = demand ldap_tls_cacertdir = /etc/openldap/cacerts ldap_search_timeout = 5 cache_credentials = true enumerate = true entry_cache_timeout = 5400
Any tips on how to prevent needing to restart sssd?
Franky
On Thu, Aug 23, 2012 at 11:07:31AM +0200, Franky Van Liedekerke wrote:
Hi,
I just had a weird situation: one of my servers suddenly no longer allowed me to log in (pam auth via sssd). Looking in the log for sssd, I had this message once every minute:
[sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
Also, "getent passwd" no longer showed any ldap users. Everything seemed correct, also the ldap servers, so I just restarted the sssd daemon and all was well again. Shouldn't the retry options of sssd just do that? I have this as sssd config (obfuscated a bit):
Most likely this means the Data Provider had crashed. Can you check syslog for messages that would indicate a crash?
The Data Provider should have respawned and the PAM Provider should have reconnected, though..I just ran a quick-n-dirty test locally, killed the sssb_be process and the sssd_pam reconnected fine for me..
Unfortunately it seems that debugging is completely off according to your config file, I assume that there is nothing interesting in /var/log/sssd/*.log ?
On 2012-08-23 11:18, Jakub Hrozek wrote:
On Thu, Aug 23, 2012 at 11:07:31AM +0200, Franky Van Liedekerke wrote:
Hi,
I just had a weird situation: one of my servers suddenly no longer allowed me to log in (pam auth via sssd). Looking in the log for sssd, I had this message once every minute:
[sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
Also, "getent passwd" no longer showed any ldap users. Everything seemed correct, also the ldap servers, so I just restarted the sssd daemon and all was well again. Shouldn't the retry options of sssd just do that? I have this as sssd config (obfuscated a bit):
Most likely this means the Data Provider had crashed. Can you check syslog for messages that would indicate a crash?
The Data Provider should have respawned and the PAM Provider should have reconnected, though..I just ran a quick-n-dirty test locally, killed the sssb_be process and the sssd_pam reconnected fine for me..
Unfortunately it seems that debugging is completely off according to your config file, I assume that there is nothing interesting in /var/log/sssd/*.log ?
In sssd_pam, I have these messages starting from Aug 19 (every minute):
(Sun Aug 19 05:09:28 2012) [sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
but in syslog I only have this one line from Aug 20:
Aug 20 16:46:45 bqsma0001ap sssd[be[LDAP]]: LDAP connection error: (null)
For the rest there's no log (since of course it's a prod system). Is there a logging level I can safely set that will not fill my partition? Also, for completeness: version sssd-1.5.1-66.el6_2.3.x86_64 on CentOS 6.2. Maybe some patch after that version fixed it, since 1.8 is already released.
Franky
On Thu, Aug 23, 2012 at 11:24:55AM +0200, Franky Van Liedekerke wrote:
On 2012-08-23 11:18, Jakub Hrozek wrote:
On Thu, Aug 23, 2012 at 11:07:31AM +0200, Franky Van Liedekerke wrote:
Hi,
I just had a weird situation: one of my servers suddenly no longer allowed me to log in (pam auth via sssd). Looking in the log for sssd, I had this message once every minute:
[sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
Also, "getent passwd" no longer showed any ldap users. Everything seemed correct, also the ldap servers, so I just restarted the sssd daemon and all was well again. Shouldn't the retry options of sssd just do that? I have this as sssd config (obfuscated a bit):
Most likely this means the Data Provider had crashed. Can you check syslog for messages that would indicate a crash?
The Data Provider should have respawned and the PAM Provider should have reconnected, though..I just ran a quick-n-dirty test locally, killed the sssb_be process and the sssd_pam reconnected fine for me..
Unfortunately it seems that debugging is completely off according to your config file, I assume that there is nothing interesting in /var/log/sssd/*.log ?
In sssd_pam, I have these messages starting from Aug 19 (every minute):
(Sun Aug 19 05:09:28 2012) [sssd[pam]] [pam_dp_reconnect_init] (0): Could not reconnect to LDAP provider.
but in syslog I only have this one line from Aug 20:
Aug 20 16:46:45 bqsma0001ap sssd[be[LDAP]]: LDAP connection error: (null)
Ah, I was really expecting that the system would report that sssd_be crashed. In general, running abrtd should catch all the crashes without admin intervention.
For the rest there's no log (since of course it's a prod system). Is there a logging level I can safely set that will not fill my partition?
debug_level = 6 or maybe 7 (1.5.x doesn't support the new hexa debug levels yet) might be a good start.
I wouldn't worry too much about the logs filling the partition up, the SSSD ships with a logrotate file and only level 9 gets really really noisy.
Also, for completeness: version sssd-1.5.1-66.el6_2.3.x86_64 on CentOS 6.2. Maybe some patch after that version fixed it, since 1.8 is already released.
Hmm, the bug I had in mind initially (#743841) was already fixed in the version you are running. The 1.8 branch has quite a few fixes and enhancements, I can recommend an upgrade from 1.5.x on a RHEL6 system.
sssd-devel@lists.fedorahosted.org
-
Franky Van Liedekerke -
Jakub Hrozek