-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forwarding back to the sssd-users list, because it contains useful information that other developers might need to see. Please make sure to keep this list in all replies.
So this confirms my hypothesis. Something is happening during the RootDSE lookup that is causing the SSSD to freeze forever here. The monitor notices this after 30s and sends a SIGTERM, which is never handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
Brandon, can you tell us the exact version of SSSD you are using? You can get this by running 'rpm -q sssd'. Please report the entire string it gives back.
- -------- Original Message -------- Subject: Re: [SSSD-users] ldap config Date: Fri, 26 Apr 2013 09:13:13 -0700 From: Brandon Foster brandon.foster@liferay.com To: Stephen Gallagher sgallagh@redhat.com
On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 04/25/2013 05:49 PM, Brandon Foster wrote:
No, i never tried to log in during that time, and I did not shut it down manually, it must have crashed.
So adding in that time out line seems to have done something. Now with the timeout line it wont even search ldap for my user. the search does not show up in sssd_default.log, and it still returns no such user.
here is my sssd.conf with the timeout line:
------------------------- [sssd] config_file_version = 2 services = nss, pam domains = default
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/default] timeout = 5400 auth_provider = ldap debug_level = 9 enumerate = True cache_credentials = True chpass_provider = ldap entry_cache_timeout = 600 ldap_chpass_uri = ldaps://66.117.7.48:11389/ id_provider = ldap ldap_group_member = uniquemember ldap_group_object_class = group ldap_id_use_start_tls = False ldap_pwd_policy = none ldap_search_base = ou=Liferay, Inc.,ou=Organizations,ou=liferay.com,o=Liferay ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri = ldaps://66.117.7.48:11389/ ldap_user_gecos = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn ldap_user_object_class = user -----------------------
good news is it isnt crashing anymore. but still not working
Ok, so what that suggests to me is that the problem was never *actually* a crash, but instead may have been a tight loop problem. The sssd_be may have gotten into an infinite loop, which prevents it from replying to the ping from the service monitor, which eventually kills it forcibly.
Let's try to verify this hypothesis. Please add 'debug_level = 9' to your [sssd] section, remove the 'timeout = 5400' from the [domain/default] section, truncate or delete the logs in /var/log/sssd and restart sssd.
Then *run the user login* and send us /var/log/sssd/sssd.log and /var/log/sssd/sssd_default.log
This should hopefully give us enough to go on. Sorry for the repeated back-and-forth, but debugging without being able to reproduce the problem locally is tricky.
Side-note: I notice you are using "uniquemember" for the member attribute, but you're not setting ldap_schema = rfc2307bis. If I remember correctly 'uniquemember' (like 'member') stores the user/group DN, not the username. If that's correct, you really need to set 'ldap_schema = rfc2307bis' or you won't see group memberships correctly.
thanks again for your help.
as far as the uniquemember, what should this be to be the username? Also i dont know which schema my ldap is but i've tried both and neither has worked with the current set up.
just as an example i have a user who's dn is: cn=testuser,ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=domain
and i want him to log in as testuser. would I then set ldap_group_member to cn?
i've attached the complete sssd.log and sssd_default.log
On Fri, Apr 26, 2013 at 9:19 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forwarding back to the sssd-users list, because it contains useful information that other developers might need to see. Please make sure to keep this list in all replies.
So this confirms my hypothesis. Something is happening during the RootDSE lookup that is causing the SSSD to freeze forever here. The monitor notices this after 30s and sends a SIGTERM, which is never handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
Brandon, can you tell us the exact version of SSSD you are using? You can get this by running 'rpm -q sssd'. Please report the entire string it gives back.
- -------- Original Message --------
Subject: Re: [SSSD-users] ldap config Date: Fri, 26 Apr 2013 09:13:13 -0700 From: Brandon Foster brandon.foster@liferay.com To: Stephen Gallagher sgallagh@redhat.com
On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 04/25/2013 05:49 PM, Brandon Foster wrote:
No, i never tried to log in during that time, and I did not shut it down manually, it must have crashed.
So adding in that time out line seems to have done something. Now with the timeout line it wont even search ldap for my user. the search does not show up in sssd_default.log, and it still returns no such user.
here is my sssd.conf with the timeout line:
------------------------- [sssd] config_file_version = 2 services = nss, pam domains = default
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/default] timeout = 5400 auth_provider = ldap debug_level = 9 enumerate = True cache_credentials = True chpass_provider = ldap entry_cache_timeout = 600 ldap_chpass_uri = ldaps://66.117.7.48:11389/ id_provider = ldap ldap_group_member = uniquemember ldap_group_object_class = group ldap_id_use_start_tls = False ldap_pwd_policy = none ldap_search_base = ou=Liferay, Inc.,ou=Organizations,ou=liferay.com,o=Liferay ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri = ldaps://66.117.7.48:11389/ ldap_user_gecos = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn ldap_user_object_class = user -----------------------
good news is it isnt crashing anymore. but still not working
Ok, so what that suggests to me is that the problem was never *actually* a crash, but instead may have been a tight loop problem. The sssd_be may have gotten into an infinite loop, which prevents it from replying to the ping from the service monitor, which eventually kills it forcibly.
Let's try to verify this hypothesis. Please add 'debug_level = 9' to your [sssd] section, remove the 'timeout = 5400' from the [domain/default] section, truncate or delete the logs in /var/log/sssd and restart sssd.
Then *run the user login* and send us /var/log/sssd/sssd.log and /var/log/sssd/sssd_default.log
This should hopefully give us enough to go on. Sorry for the repeated back-and-forth, but debugging without being able to reproduce the problem locally is tricky.
Side-note: I notice you are using "uniquemember" for the member attribute, but you're not setting ldap_schema = rfc2307bis. If I remember correctly 'uniquemember' (like 'member') stores the user/group DN, not the username. If that's correct, you really need to set 'ldap_schema = rfc2307bis' or you won't see group memberships correctly.
thanks again for your help.
as far as the uniquemember, what should this be to be the username? Also i dont know which schema my ldap is but i've tried both and neither has worked with the current set up.
just as an example i have a user who's dn is: cn=testuser,ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=domain
and i want him to log in as testuser. would I then set ldap_group_member to cn?
i've attached the complete sssd.log and sssd_default.log
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlF6qPcACgkQeiVVYja6o6OvvgCfShTffrzINj64pTg/sWgqQiDn GdwAn1qLAuMkzG9yzxoJaBxz3DnANHH5 =fwPX -----END PGP SIGNATURE-----
yep sorry, was getting lazy with hitting reply.
here is my ssd version ------ root@virt-vm-99:~> rpm -q sssd sssd-1.9.2-82.4.el6_4.x86_64 --------
On Fri, Apr 26, 2013 at 12:19:05PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forwarding back to the sssd-users list, because it contains useful information that other developers might need to see. Please make sure to keep this list in all replies.
So this confirms my hypothesis. Something is happening during the RootDSE lookup that is causing the SSSD to freeze forever here. The monitor notices this after 30s and sends a SIGTERM, which is never handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
Brandon, can you tell us the exact version of SSSD you are using? You can get this by running 'rpm -q sssd'. Please report the entire string it gives back.
I haven't had yet the time to investigate fully but we're looking at either a tight loop or a request that never finishes.
Brandon, could you run an instrumented test build for us in case we fail to reproduce the problem locally?
sure, what would i need to do exactly?
On Mon, Apr 29, 2013 at 5:08 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Fri, Apr 26, 2013 at 12:19:05PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forwarding back to the sssd-users list, because it contains useful information that other developers might need to see. Please make sure to keep this list in all replies.
So this confirms my hypothesis. Something is happening during the RootDSE lookup that is causing the SSSD to freeze forever here. The monitor notices this after 30s and sends a SIGTERM, which is never handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
Brandon, can you tell us the exact version of SSSD you are using? You can get this by running 'rpm -q sssd'. Please report the entire string it gives back.
I haven't had yet the time to investigate fully but we're looking at either a tight loop or a request that never finishes.
Brandon, could you run an instrumented test build for us in case we fail to reproduce the problem locally?
sssd-devel@lists.fedorahosted.org