Description of problem: Since sssd 1.13 has been crashing, downgrading to 1.12, seems to solve the problem. I get the following trace: Stack trace of thread 8379: #0 0x00007fac4d7d2a98 raise (libc.so.6) #1 0x00007fac4d7d469a abort (libc.so.6) #2 0x00007fac5168d3b4 _dbus_abort (libdbus-1.so.3) #3 0x00007fac51683e3e _dbus_warn_check_failed (libdbus-1.so.3) #4 0x00007fac51675d96 dbus_message_iter_append_basic (libdbus-1.so.3) #5 0x00007fac51676698 dbus_message_append_args_valist (libdbus-1.so.3) #6 0x00007fac51d1c329 sbus_request_return_and_finish (libsss_util.so) #7 0x000055865389b3f3 acctinfo_callback (sssd_be) #8 0x00007fac427e0d19 sdap_account_info_complete (libsss_ldap_common.so) #9 0x00007fac427ddfe0 users_get_done (libsss_ldap_common.so) #10 0x00007fac4df7c1c2 _tevent_req_error (libtevent.so.0) #11 0x00007fac4df7c1c2 _tevent_req_error (libtevent.so.0) #12 0x00007fac427f6314 sdap_search_user_process (libsss_ldap_common.so) #13 0x00007fac427f137c generic_ext_search_handler.isra.3 (libsss_ldap_common.so) #14 0x00007fac427f2ee3 sdap_get_generic_op_finished (libsss_ldap_common.so) #15 0x00007fac427f22fd sdap_process_result (libsss_ldap_common.so) #16 0x00007fac4df803c3 epoll_event_loop_once (libtevent.so.0) #17 0x00007fac4df7e907 std_event_loop_once (libtevent.so.0) #18 0x00007fac4df7b11d _tevent_loop_once (libtevent.so.0) #19 0x00007fac4df7b2bb tevent_common_loop_wait (libtevent.so.0) #20 0x00007fac4df7e8a7 std_event_loop_wait (libtevent.so.0) #21 0x00007fac51d21fd3 server_loop (libsss_util.so) #22 0x000055865389ab76 main (sssd_be) #23 0x00007fac4d7be580 __libc_start_main (libc.so.6) #24 0x000055865389ac09 _start (sssd_be) Version-Release number of selected component (if applicable): sssd-1.13.0-7.fc23.x86_64 How reproducible: Config sssd with something like this: [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam, autofs domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/default] auth_provider = ldap ldap_tls_reqcert = never ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=foo,dc=bar krb5_realm = EXAMPLE.COM chpass_provider = ldap id_provider = ldap use_fully_qualified_names = False store_legacy_passwords = False debug_level = 0 min_id = 100 ldap_uri = ldap://example.com enumerate = True autofs_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts [autofs] and enable sssd in authconfig. Start sssd service and wait for crash.
Can you please also upload the logs and the corefile?
where do I find the core file? Anything I need to config to get core file from sssd?
abrt should help you with that, abrt-cli might print where the corefiles are. Normally they're at /var/spool/abrt/ IIRC. But since we switched to calling setuid and drop privileges, the corefiles might not be generated automatically. In that case, you can attach gdb as described here: https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs How to get debug files is described here: https://fedorahosted.org/sssd/wiki/Troubleshooting
Thanks, I have removed all abrt* packages any way, let me see what I can out from gdb.
(In reply to Terje Røsten from comment #4) > Thanks, I have removed all abrt* packages any way, let me see what I can out > from gdb. You should be able t obtain coredump even without abrt. You might take a look into coredumpctl[1]. If you didn't change core_pattern manually. [root@host ~]# cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e [1] http://www.freedesktop.org/software/systemd/man/coredumpctl.html If you are able to reproduce crash. We might also try to run sssd with valgrind.
In general Terje, please let us know if we can help reproduce the issue or get the core file!
ping? Can we help you get the debug information?
It seems to be related to your locales. I was able to reproduce with setting locales to "norwegian" So the workaround is to add line "LANG=C" to the /etc/sysconfig/sssd.
So far so good, thanks guys!
Upstream ticket: https://fedorahosted.org/sssd/ticket/2861
Fixed upstream: master: 6b01dae732eedee808f32a9cdd4b5656a9f839c4 e8ae3af6724164048a85c374ea8045a368a2d34e 8bc6bc6d87127d615f7a81d7151cb46007feff63 sssd-1-13: 620b2adf7c19c1b9abc456c37926d77649d262b7 518c003f3d555a525fe3aebf60366e0c0716eff4 b51ed15a72a3c8542f3dab72158aeee1d7254341
sssd-1.13.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-f779615d41
sssd-1.13.2-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-546a9345da
sssd-1.13.2-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update sssd' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-546a9345da
sssd-1.13.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update sssd' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f779615d41
sssd-1.13.2-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.13.2-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.