-----BEGIN PGP SIGNED MESSAGE-----
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(a)liferay.com>
To: Stephen Gallagher <sgallagh(a)redhat.com>
On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher <sgallagh(a)redhat.com>
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 =
> [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://22.214.171.124: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://126.96.36.199: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
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
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:
and i want him to log in as testuser. would I then set ldap_group_member
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/
-----END PGP SIGNATURE-----