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?