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 1392444 - sssd_be keeps crashing
Summary: sssd_be keeps crashing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Madhuri
URL:
Whiteboard:
: 1393133 1404560 (view as bug list)
Depends On:
Blocks: 1396485 1396494 1399979
TreeView+ depends on / blocked
 
Reported: 2016-11-07 14:14 UTC by Ming Davies
Modified: 2020-09-10 09:55 UTC (History)
18 users (show)

Fixed In Version: sssd-1.15.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1396485 (view as bug list)
Environment:
Last Closed: 2017-08-01 09:00:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sssd debug log (68.79 KB, application/x-gzip)
2016-11-07 16:58 UTC, Ming Davies 		no flags Details
sssd debug after replacing auth_provider=ad (110.92 KB, application/x-gzip)
2016-11-08 12:31 UTC, Ming Davies 		no flags Details
sssd debug after removing ad_provider (107.20 KB, application/x-gzip)
2016-11-08 12:32 UTC, Ming Davies 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4267 0 None closed sssd_be keeps crashing 2020-10-06 05:44:51 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Ming Davies 2016-11-07 14:14:14 UTC 
Description of problem:
Customer said that SSSD was updated as part of yum update command from  RHEL 7.2 to RHEL 7.3, since then sssd keeps crashing whenever they attempted to start sssd.service.

messages:Nov  4 12:26:47 koror abrt-hook-ccpp: Process 30558 (sssd_be) of user 0 killed by SIGSEGV - dumping core
messages:Nov  4 12:26:47 koror abrt-hook-ccpp: Process 30561 (sssd_be) of user 0 killed by SIGSEGV - ignoring (repeated crash)
messages:Nov  4 12:26:49 koror abrt-hook-ccpp: Process 30599 (sssd_be) of user 0 killed by SIGSEGV - ignoring (repeated crash)
messages:Nov  4 12:26:53 koror abrt-hook-ccpp: Process 30941 (sssd_be) of user 0 killed by SIGSEGV - ignoring (repeated crash)


From yum.log:
Nov 04 12:22:18 Updated: sssd-common-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-krb5-common-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-common-pac-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-ad-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-ipa-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-ldap-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-krb5-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-proxy-1.14.0-43.el7.x86_64
Nov 04 12:22:18 Updated: sssd-1.14.0-43.el7.x86_64

Version-Release number of selected component (if applicable):
sssd-1.14.0-43.el7.x86_64                                   Fri Nov  4 12:22:18 2016


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
From the core dump:
Core was generated by `/usr/libexec/sssd/sssd_be --domain redecorp --uid 0 --gid 0 --debug-to-files'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fa2766492a2 in ad_subdom_reinit (subdoms_ctx=subdoms_ctx@entry=0x7fa286512aa0) at src/providers/ad/ad_subdomains.c:626
626	    canonicalize = dp_opt_get_bool(

(gdb) backtrace
#0  0x00007fa2766492a2 in ad_subdom_reinit (subdoms_ctx=subdoms_ctx@entry=0x7fa286512aa0) at src/providers/ad/ad_subdomains.c:626
#1  0x00007fa27664afb3 in ad_subdomains_init (mem_ctx=<optimized out>, be_ctx=0x7fa2864b9540, ad_id_ctx=<optimized out>, dp_methods=0x7fa2865186a0)
    at src/providers/ad/ad_subdomains.c:1528
#2  0x00007fa2857552d6 in dp_target_run_constructor (be_ctx=0x7fa2864b9540, target=0x7fa2864d4bc0) at src/providers/data_provider/dp_targets.c:246
#3  dp_target_init (target=0x7fa2864d4bc0, modules=0x7fa2864d3840, provider=0x7fa2864d3b60, be_ctx=0x7fa2864b9540)
    at src/providers/data_provider/dp_targets.c:358
#4  dp_load_targets (modules=0x7fa2864d3840, targets=0x7fa2864d4a70, provider=0x7fa2864d3b60, be_ctx=0x7fa2864b9540)
    at src/providers/data_provider/dp_targets.c:484
#5  dp_init_targets (mem_ctx=mem_ctx@entry=0x7fa2864d3b60, be_ctx=be_ctx@entry=0x7fa2864b9540, provider=provider@entry=0x7fa2864d3b60, 
    modules=0x7fa2864d3840) at src/providers/data_provider/dp_targets.c:530
#6  0x00007fa28575466b in dp_init (ev=0x7fa2864b0c10, be_ctx=be_ctx@entry=0x7fa2864b9540, uid=<optimized out>, gid=0)
    at src/providers/data_provider/dp.c:120
#7  0x00007fa28574cc77 in be_process_init (mem_ctx=<optimized out>, be_domain=0x7fa2864aa220 "redecorp", uid=<optimized out>, gid=0, 
    ev=0x7fa2864b0c10, cdb=0x7fa2864b2170) at src/providers/data_provider_be.c:450
#8  0x00007fa28574ba59 in main (argc=8, argv=<optimized out>) at src/providers/data_provider_be.c:562

(gdb) frame 1
#1  0x00007fa27664afb3 in ad_subdomains_init (mem_ctx=<optimized out>, be_ctx=0x7fa2864b9540, ad_id_ctx=<optimized out>, dp_methods=0x7fa2865186a0)
    at src/providers/ad/ad_subdomains.c:1528
1528	    ret = ad_subdom_reinit(sd_ctx);
(gdb) list
1523	        DEBUG(SSSDBG_CRIT_FAILURE, "Unable to setup ptask "
1524	              "[%d]: %s\n", ret, sss_strerror(ret));
1525	        /* Ignore, responders will trigger refresh from time to time. */
1526	    }
1527	
1528	    ret = ad_subdom_reinit(sd_ctx);
1529	    if (ret != EOK) {
1530	        DEBUG(SSSDBG_MINOR_FAILURE, "Could not reinitialize subdomains. "
1531	              "Users from trusted domains might not be resolved correctly\n");
1532	        /* Ignore this error and try to discover the subdomains later */
Comment 3 Lukas Slebodnik 2016-11-07 14:52:12 UTC 
Could you also attach log file with debug_level = 9 in domain section?
Comment 4 Lukas Slebodnik 2016-11-07 15:06:39 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3234
Comment 7 Sumit Bose 2016-11-07 16:26:11 UTC 
The crash is triggered by 'auth_provider = krb5' (and 'chpass_provider = krb5'). Setting it to 'ad' or just removing it should fix it.

Is there a reason for using 'krb5' and not 'ad' here?

I'll try to prepare a fix.
Comment 9 Ming Davies 2016-11-07 16:58:45 UTC 
Created attachment 1218144 [details]
sssd debug log
Comment 13 Ming Davies 2016-11-08 12:31:27 UTC 
Created attachment 1218511 [details]
sssd debug after replacing auth_provider=ad
Comment 14 Ming Davies 2016-11-08 12:32:38 UTC 
Created attachment 1218513 [details]
sssd debug after removing ad_provider
Comment 20 Sumit Bose 2016-11-09 07:21:14 UTC 
*** Bug 1393133 has been marked as a duplicate of this bug. ***
Comment 29 Sumit Bose 2016-12-14 08:33:51 UTC 
*** Bug 1404560 has been marked as a duplicate of this bug. ***
Comment 32 Madhuri 2017-05-16 05:52:31 UTC 
Tested with 
sssd-1.15.2-29.el7.x86_64

Steps followed during verification:
1) System was updated using # yum update
2) Configured sssd on client.
3) Set id_provider=ad and auth_provider= krb5 in sssd.conf.
4) Started sssd service.
5) Checked user lookup.

form yum.log:
May 15 07:55:20 Updated: python-sssdconfig-1.15.2-29.el7.noarch
May 15 07:56:36 Updated: sssd-client-1.15.2-29.el7.x86_64
May 15 07:57:42 Updated: sssd-common-1.15.2-29.el7.x86_64
May 15 07:57:43 Updated: sssd-krb5-common-1.15.2-29.el7.x86_64
May 15 07:57:45 Updated: sssd-common-pac-1.15.2-29.el7.x86_64
May 15 07:58:02 Updated: sssd-ipa-1.15.2-29.el7.x86_64
May 15 07:58:07 Updated: sssd-krb5-1.15.2-29.el7.x86_64
May 15 07:58:07 Updated: sssd-ldap-1.15.2-29.el7.x86_64
May 15 07:58:08 Updated: sssd-proxy-1.15.2-29.el7.x86_64
May 15 07:58:10 Updated: sssd-ad-1.15.2-29.el7.x86_64
May 15 07:58:41 Updated: sssd-1.15.2-29.el7.x86_64

# cat  /etc/sssd/sssd.conf | grep provider
id_provider = ad
auth_provider = krb5

# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/sssd.service.d
           └─journal.conf
   Active: active (running) since Mon 2017-05-15 08:26:14 EDT; 17h ago
 Main PID: 8516 (sssd)
   CGroup: /system.slice/sssd.service
           ├─8516 /usr/sbin/sssd -i -f
           ├─8517 /usr/libexec/sssd/sssd_be --domain EXAMPLE.COM --uid 0 --gid 0 --debug-to-files
           ├─8518 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
           └─8519 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files

# getent passwd administrator
administrator:*:217800500:217800513:Administrator:/home/EXAMPLE.COM/administrator:/bin/bash

# id administrator
uid=217800500(administrator) gid=217800513 groups=217800513
Comment 33 errata-xmlrpc 2017-08-01 09:00:03 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294
Note You need to log in before you can comment on or make changes to this bug.