Hide Forgot
Description of problem: Internal error in domain log for large id numbers Version-Release number of selected component (if applicable): 1.11.2-24.el7 How reproducible: Occasionally Steps to Reproduce: 1. Join sssd to the AD Server via realmd tool. 2. I see the message in domain logs with starting up sssd. Don't have the exact reproducer right now. Jakub, since you were able to access my system and submit patches, do you also have a reproducer? Actual results: (Thu Jan 16 14:52:06 2014) [sssd[be[sssdad.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=4294967295] (Thu Jan 16 14:52:06 2014) [sssd[be[sssdad.com]]] [be_req_set_domain] (0x0400): Changing request domain from [sssdad.com] to [sssdad.com] (Thu Jan 16 14:52:06 2014) [sssd[be[sssdad.com]]] [ad_account_can_shortcut] (0x0080): Mapping ID [4294967295] to SID failed: [IDMAP domain not found] (Thu Jan 16 14:52:06 2014) [sssd[be[sssdad.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Internal Error (Memory buffer error) Expected results: Additional info:
To reproduce, it should be enough to do: getent passwd 4294967295 On an AD client. The bug shouldn't abort the request completely, the function that errored out was an optimization.
Upstream ticket: https://fedorahosted.org/sssd/ticket/2200
Fixed upstream: master: 82234f3cc55b6faa954f2ad11968139ae0533f7d sssd-1-11: 76b51d84d01692a2e1300a9e45a0851258295fb6
I still see internal error in the logs. Shouldn't the internal error go away with the fix? # getent passwd 4294967295 # echo $? 2 Log shows: (Wed Jan 22 11:35:58 2014) [sssd[be[sssdad2012.com]]] [ad_account_can_shortcut] (0x0080): Mapping ID [4294967295] to SID failed: [IDMAP domain not found] (Wed Jan 22 11:35:58 2014) [sssd[be[sssdad2012.com]]] [ad_account_info_handler] (0x0400): Cannot determine the right domain: Input/output error (Wed Jan 22 11:35:58 2014) [sssd[be[sssdad2012.com]]] [users_get_send] (0x0080): Mapping ID [4294967295] to SID failed: [IDMAP domain not found] (Wed Jan 22 11:35:58 2014) [sssd[be[sssdad2012.com]]] [ad_account_info_complete] (0x0010): Bug: dp_error is OK on failed request(Wed Jan 22 11:35:58 2014) [sssd[be[sssdad2012.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Internal Error (Memory buffer error)
You're right, the internal error should go away. I reproduced the bug now and I see the error message is coming from a different location now -- so the request goes through (previously it just aborted) but returns with an unexpected combination of error codes. I'll look further.
OK, I have a patch now, we fail further calling the same function. Feel free to mark this bug as ASSIGNED.
Re-opening this bug to have another fix for the internal error. Tested with version 1.11.2-29.el7
Additional fixes landed upstream: master: 6095e82a99cc1c1fcac5e00f0a770302cc46eb2b sssd-1-11: 3a091bd11739af7807b394470bb7a7f3c42f7b7b
Verified in version 1.11.2-37.el7 Log now shows: (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=4294967295] (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [be_req_set_domain] (0x0400): Changing request domain from [sssdad.com] to [sssdad.com] (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [ad_account_can_shortcut] (0x0080): Mapping ID [4294967295] to SID failed: [IDMAP domain not found] (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [ad_account_info_handler] (0x0400): Cannot determine the right domain: Input/output error (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [users_get_send] (0x0080): [4294967295] did not match any configured ID mapping domain (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [sysdb_search_user_by_uid] (0x0400): No such entry (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Thu Jan 30 08:15:33 2014) [sssd[be[sssdad.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.