RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1093795 - sssd_be segfaulting
Summary: sssd_be segfaulting
Keywords:
Status: CLOSED DUPLICATE of bug 1071823
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-02 17:00 UTC by Brian J. Murrell
Modified: 2020-05-02 17:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-05 13:17:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FedoraHosted SSSD 2325 0 None None None Never
Github SSSD sssd issues 3367 0 None None None 2020-05-02 17:42:16 UTC

Description Brian J. Murrell 2014-05-02 17:00:15 UTC 
Description of problem:
sssd_be is segfaulting

Version-Release number of selected component (if applicable):
1.9.2-129.el6_5.4

How reproducible:
100% eventually

Steps to Reproduce:
1. not really sure
2.
3.

Actual results:
Segfaults

Expected results:
Shouldn't segfault

Additional info:

From the upstream bug report: https://fedorahosted.org/sssd/ticket/2325 here's the stack trace:

Thread 1 (Thread 0x7fa5213cc700 (LWP 16330)):
#0  0x000000000040f68c in be_host_handler (message=<value optimized out>, conn=0x256d0c0)
    at src/providers/data_provider_be.c:1847
        req = <value optimized out>
        be_req = 0x258ca10
        becli = 0x2570cd0
        reply = 0x259fe50
        dbus_error = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 1, dummy3 = 1, dummy4 = 1, dummy5 = 1, 
          padding1 = 0x374062800e}
        dbret = <value optimized out>
        user_data = <value optimized out>
        flags = 0
        filter = 0x35b44a8 "name=ssh-1.example.com:ssh-1"
        ret = <value optimized out>
        err_maj = 0
        err_min = 32767
        err_msg = 0x72 <Address 0x72 out of bounds>
        __FUNCTION__ = "be_host_handler"
#1  0x000000000046059f in sbus_message_handler (dbus_conn=<value optimized out>, message=0x2578f60, 
    user_data=<value optimized out>) at src/sbus/sssd_dbus_connection.c:430
        intf_p = 0x256cb30
        method = 0x259b1f8 "hostHandler"
        path = <value optimized out>
        msg_interface = <value optimized out>
        reply = 0x0
        i = <value optimized out>
        ret = <value optimized out>
        found = 1
        __FUNCTION__ = "sbus_message_handler"
#2  0x000000374061cefe in _dbus_object_tree_dispatch_and_unlock (tree=0x256d050, message=0x2578f60)
    at dbus-object-tree.c:856
        message_function = 0x460310 <sbus_message_handler>
        user_data = <value optimized out>
        next = 0x0
        path = 0x253eb20
        exact_match = 0
        list = 0x2577dc0
        link = <value optimized out>
        result = DBUS_HANDLER_RESULT_NOT_YET_HANDLED
        subtree = <value optimized out>
#3  0x0000003740610b4c in dbus_connection_dispatch (connection=0x256c9d0) at dbus-connection.c:4492
        message = 0x2578f60
        link = <value optimized out>
        filter_list_copy = 0x0
        message_link = 0x2577e80
        result = <value optimized out>
        pending = <value optimized out>
        reply_serial = <value optimized out>
        status = <value optimized out>
        __FUNCTION__ = "dbus_connection_dispatch"
#4  0x00000000004628be in sbus_dispatch (ev=0x25385b0, te=<value optimized out>, tv=..., data=<value optimized out>)
    at src/sbus/sssd_dbus_connection.c:104
        new_event = <value optimized out>
        conn = 0x256d0c0
        dbus_conn = 0x256c9d0
        ret = <value optimized out>
        __FUNCTION__ = "sbus_dispatch"
#5  0x0000003743207c91 in tevent_common_loop_timer_delay (ev=0x25385b0) at ../tevent_timed.c:341
        current_time = {tv_sec = 1398803041, tv_usec = 943537}
        te = 0x35b0010
#6  0x0000003743208cbb in epoll_event_loop_once (ev=0x25385b0, location=<value optimized out>) at ../tevent_epoll.c:916
        epoll_ev = 0x25387c0
        tval = {tv_sec = 263, tv_usec = 71635}
        panic_triggered = false
#7  0x00000037432072e6 in std_event_loop_once (ev=0x25385b0, location=0x4828d3 "src/util/server.c:601")
    at ../tevent_standard.c:112
        glue_ptr = <value optimized out>
        glue = 0x2538690
        ret = <value optimized out>
#8  0x000000374320349d in _tevent_loop_once (ev=0x25385b0, location=0x4828d3 "src/util/server.c:601") at ../tevent.c:530
        ret = <value optimized out>
        nesting_stack_ptr = 0x0
#9  0x000000374320351b in tevent_common_loop_wait (ev=0x25385b0, location=0x4828d3 "src/util/server.c:601")
    at ../tevent.c:634
        ret = <value optimized out>
#10 0x0000003743207256 in std_event_loop_wait (ev=0x25385b0, location=0x4828d3 "src/util/server.c:601")
    at ../tevent_standard.c:138
        glue_ptr = <value optimized out>
        glue = 0x2538690
        ret = <value optimized out>
#11 0x0000000000466c33 in server_loop (main_ctx=0x2539920) at src/util/server.c:601
No locals.
#12 0x000000000041a526 in main (argc=<value optimized out>, argv=<value optimized out>)
    at src/providers/data_provider_be.c:2755
        opt = <value optimized out>
        pc = <value optimized out>
        be_domain = 0x2537400 "example.com"
        srv_name = <value optimized out>
        main_ctx = 0x2539920
        confdb_path = <value optimized out>
        ret = <value optimized out>
        long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x68c7c0, val = 0, 
            descrip = 0x4755ef "Help options:", argDescrip = 0x0}, {longName = 0x4755fd "debug-level", shortName = 100 'd', 
            argInfo = 2, arg = 0x68c8a0, val = 0, descrip = 0x4755ce "Debug level", argDescrip = 0x0}, {
            longName = 0x475609 "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x68c8a4, val = 0, 
            descrip = 0x476be0 "Send the debug output to files instead of stderr", argDescrip = 0x0}, {
            longName = 0x475618 "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x68c7a8, val = 0, 
            descrip = 0x4755da "Add debug timestamps", argDescrip = 0x0}, {longName = 0x475629 "debug-microseconds", 
            shortName = 0 '\000', argInfo = 2, arg = 0x68c7ac, val = 0, 
            descrip = 0x476c18 "Show timestamps with microseconds", argDescrip = 0x0}, {longName = 0x4778dc "domain", 
            shortName = 0 '\000', argInfo = 1, arg = 0x7fff46cf4e78, val = 0, 
            descrip = 0x476c40 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, 
            shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}}
        __FUNCTION__ = "main"
Comment 2 Jakub Hrozek 2014-05-02 18:02:04 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2325
Comment 3 Lukas Slebodnik 2014-05-02 20:47:34 UTC 
This bug seems to be duplicate of BZ1019285 or BZ1071823.
If I remember correctly, this problem is reproducible if system was configured to utilize integration sssd with ssh and id_provider ldap is used.
The integfration with ssh could be configured by ipa-client-install. 
Do you use sssd as a ipa-client?
Comment 4 Brian J. Murrell 2014-05-04 18:42:46 UTC 
(In reply to Lukas Slebodnik from comment #3)
> Do you use sssd as a ipa-client?

Yes.
Comment 5 Lukas Slebodnik 2014-05-05 06:50:18 UTC 
Could you check your sssd.conf if there is domain with id_provider ldap?
sssd should not crash with id_provider ipa. The best way would be if you could attach sssd.conf to this ticket.
Comment 6 Brian J. Murrell 2014-05-05 11:52:10 UTC 
(In reply to Lukas Slebodnik from comment #5)
> Could you check your sssd.conf if there is domain with id_provider ldap?

Yes, there is.

[domain/EXAMPLE.COM]
auth_provider = krb5
chpass_provider = krb5
krb5_kdcip = ipa-1, ipa-2
krb5_kpasswd = ipa-1
krb5_realm = EXAMPLE.COM
id_provider = ldap
ldap_uri = ldap://ipa-1, ldap://ipa-2
ldap_search_base = cn=accounts,dc=example,dc=com
ldap_schema = rfc2307bis
# ldap_tls_reqcert = demand
# ldap_tls_cacert = /etc/ssl/certs/slapd-ca-cert.pem
cache_credentials = true
enumerate = true
debug_level = 10

> sssd should not crash with id_provider ipa.

I have been meaning to re-work/write our sssd.conf file.  Ours current configuration has been in place/use for a number of years.  Maybe it's getting time to do that.

Maybe the best way to start is to ask to see what your idea of a well supported FreeIPA/SSSD sssd.conf looks like.
Comment 7 Jakub Hrozek 2014-05-05 11:58:23 UTC 
(In reply to Brian J. Murrell from comment #6)
> Maybe the best way to start is to ask to see what your idea of a well
> supported FreeIPA/SSSD sssd.conf looks like.

I would say you should just let ipa-client-install generate the config file. The only change to get the functionality you use then would be to enable enumeration (which I personally discourage) and check if cache_credentials is enabled in the default sssd.conf that ipa-client-install generates.
Comment 8 Jakub Hrozek 2014-05-05 12:00:50 UTC 
btw by using id_provider=ipa you'd also get better performance, by using access_provider=ipa, you'll be able to leverage HBAC access control, etc etc.
Comment 9 Brian J. Murrell 2014-05-05 13:14:00 UTC 
So yeah.  That's what I ended up doing.  FWIW, we use configuration management (i.e. chef) here and that's what was installing an older configuration of that file, after ipa-client-install was done.

So I took the result of a pristine sssd.conf from a ipa-client-install and plugged that into our configuration management system which allowed me to go back to the machines that had the older one installed and replace it with the one that ipa-client-install would have put there.

As a result the segfaults are probably gone as well as the pauses/hangs that I was getting with ssh and some nss calls.
Comment 10 Jakub Hrozek 2014-05-05 13:17:21 UTC 
(In reply to Brian J. Murrell from comment #9)
> As a result the segfaults are probably gone as well as the pauses/hangs that
> I was getting with ssh and some nss calls.

Thanks for the testing. I'll close this one as a duplicate of bug #1071823

*** This bug has been marked as a duplicate of bug 1071823 ***
Note You need to log in before you can comment on or make changes to this bug.