[SSSD] getent returns only single users

Ondrej Kos okos at redhat.com
Mon Apr 15 11:59:41 UTC 2013


On 04/15/2013 01:29 PM, 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
>>
>>> sss.log
>>> (Mon Apr 15 12:00:40 2013) [sssd] [client_registration] (0x0100):
>>> Received ID registration: (pam,1)
>>> (Mon Apr 15 12:00:40 2013) [sssd] [mark_service_as_started]
>>> (0x0200): Marking pam as started.
>>> (Mon Apr 15 12:00:40 2013) [sssd] [sbus_server_init_new_connection]
>>> (0x0200): Entering.
>>> (Mon Apr 15 12:00:40 2013) [sssd] [sbus_server_init_new_connection]
>>> (0x0200): Adding connection 0x8708c60.
>>> (Mon Apr 15 12:00:40 2013) [sssd] [sbus_init_connection] (0x0200):
>>> Adding connection 8708C60
>>> (Mon Apr 15 12:00:40 2013) [sssd] [sbus_server_init_new_connection]
>>> (0x0200): Got a connection
>>> (Mon Apr 15 12:00:40 2013) [sssd] [monitor_service_init] (0x0400):
>>> Initializing D-BUS Service
>>> (Mon Apr 15 12:00:40 2013) [sssd] [client_registration] (0x0100):
>>> Received ID registration: (nss,1)
>>> (Mon Apr 15 12:00:40 2013) [sssd] [mark_service_as_started]
>>> (0x0200): Marking nss as started.
>>> (Mon Apr 15 12:00:40 2013) [sssd] [mark_service_as_started]
>>> (0x0400): SSSD is initialized, terminating parent process
>>> (Mon Apr 15 12:00:40 2013) [sssd] [sbus_dispatch] (0x0080):
>>> Connection is not open for dispatching.
>>> (Mon Apr 15 12:00:40 2013) [sssd] [mt_svc_exit_handler] (0x0040):
>>> Child [default] terminated with signal [6]
>> Here is some more evidence, signal [6] is SIGABRT so the back end
>> crashed.
>>
>> It's quite possible that you hit
>> https://fedorahosted.org/sssd/ticket/1799,
>> if you could collect the backtrace then we would know for sure. We
>> already
>> have a patch for that problem and will include the fix in the shortly
>> upcoming
>> 1.9.5 release.
> Thanks. Our version is 1.9.4 on Ubuntu 12.10. Will gladly test anything
> on 1.9.5 and report back.
> Cheers,
> Steve
>

Hi Steve,

Does ldapsearch against the configured server work? Because from the 
provided logs, I see that there's issue with contacting it.

[sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP 
server]


-- 
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech



More information about the sssd-devel mailing list