[SSSD] getent returns only single users

Jakub Hrozek jhrozek at redhat.com
Mon Apr 15 12:09:41 UTC 2013


On Mon, Apr 15, 2013 at 01:29:52PM +0200, steve wrote:
> On 04/15/2013 12:36 PM, Jakub Hrozek wrote:
> >On Mon, Apr 15, 2013 at 12:17:33PM +0200, steve wrote:
> >>On 04/15/2013 11:33 AM, Jakub Hrozek wrote:
> >>>Have you been able to check what kind of searches (with wireshark or similar
> >>>or even just looking at the debug logs) sssd is doing? There should be
> >>>one search for users and one for groups every 300 seconds by default
> >>>(can be overriden with ldap_enumeration_refresh_timeout).
> >>>
> >>>Also how many users/groups do you have on the server?
> >>>
> >>Hi
> >>Test setup with 2 users and 2 groups. The ldap server (Samba4 AD) is
> >>flooded with requests every second. I attach small bits from each
> >>log. If you coud have a look that would be great.
> >>
> >Thanks for the logs. I suspect that what happens is that the sssd_be
> >crashes or is restarted for some reason and after being respawned starts
> >another enumeration which is why you are seeing so many searches.
> >
> >As a matter of fact, there is a patch on the list to fix a potential
> >crash when enumerating. Which version are you running? Maybe you're
> >hitting that exact problem.
> >
> >>TIA
> >>Steve
> >>
> >[snip]
> >
> >>sssd_default.log
> >[snip]
> >>(Mon Apr 15 12:00:43 2013) [sssd[be[default]]] [dp_get_options]
> >>(0x0400): Option ldap_dns_service_name has value ldap
> >>(Mon Apr 15 12:00:43 2013) [sssd[be[default]]] [dp_get_options]
> >>(0x0400): Option ldap_krb5_ticket_lifetime has value 86400
> >Is there something more in the log? The part you pasted pretty much
> >describes the option being loaded.
> Hi
> The log got bounced because it was too big. I've put it here:
> https://dl.dropboxusercontent.com/u/45150875/sssd_default.log

Thank you, I will cancel the pending request, then.

This is the most important part of the log:
(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server '192.168.1.100' as 'working'
(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [dc=dolores,dc=site]
(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(&(objectclass=user)(samAccountName=*)(uidNumber=*)(gidNumber=*))(&(objectCategory=user)(uidNumber=*)))][dc=dolores,dc=site].
(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [client_registration] (0x0100): Cancel DP ID timeout [0x9e3c5f0]
(Mon Apr 15 13:16:33 2013) [sssd[be[default]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]

Now sssd_be crashed and the two following lines are already the newly
spawned process.

(Mon Apr 15 13:16:34 2013) [sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
(Mon Apr 15 13:16:34 2013) [sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel

Judging by the log, this is a different bug :-/ Is it possible to
get the core file from the crash? Or maybe a text backtrace?

I tried to simulate the crash by setting up a firewall on my test IPA
server, but the sssd survived the test here..

As Ondra asked, can you ldapsearch the directory? When you were testing
with nss-pam-ldapd did you also use GSSAPI authentication?



More information about the sssd-devel mailing list