#1270 sssd_nss crashes on request when no back end is running
Closed: Fixed None Opened 8 years ago by dax.

uname -r
3.2.10-3.fc16.x86_64

After a few minutes when sssd is launched :
systemctl restart sssd.service

Process are :

 5628 ?        Ss     0:00 /usr/sbin/sssd -D -f
 5630 ?        S      0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
 5631 ?        S      0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
 5663 ?        R      0:00 /usr/libexec/sssd/sssd_be --domain LDAP --debug-to-files

The log says :

[root@lame4: 382] Mar 20 18:07:36 lame4 kernel: [11304.391716] sssd_be[5663]: segfault at 4000 ip 00007fc4188e64a2 sp 00007ffffbf0ce90 error 4 in sssd_be[7fc41888d000+75000]
Mar 20 18:07:36 lame4 abrtd: Directory 'ccpp-2012-03-20-18:07:36-5663' creation detected
Mar 20 18:07:36 lame4 abrt[5682]: Saved core dump of pid 5663 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-2012-03-20-18:07:36-5663 (16244736 bytes)
Mar 20 18:07:36 lame4 sssd[be[LDAP]]: Starting up
Mar 20 18:07:36 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:07:36-5663 (dup of ccpp-2012-03-20-15:04:40-828)

Process are :

 5628 ?        Ss     0:00 /usr/sbin/sssd -D -f
 5630 ?        S      0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
 5631 ?        S      0:00 /usr/libexec/sssd/sssd_pam --debug-to-files

A few minutes later log says :

Mar 20 18:29:01 lame4 abrtd: Directory 'ccpp-2012-03-20-18:29:01-5630' creation detected
Mar 20 18:29:01 lame4 abrt[6320]: Saved core dump of pid 5630 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2012-03-20-18:29:01-5630 (1622016 bytes)
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:29:01-5630 (dup of ccpp-2012-03-20-15:11:34-833)

Process are :

 5628 ?        Ss     0:00 /usr/sbin/sssd -D -f
 5631 ?        S      0:00 /usr/libexec/sssd/sssd_pam --debug-to-files

and getent passwd user doesn't work anymore

In a first time sssd_be segfaults and getent passwd user works,
ans in a second time sssd_nss try to start up and getent passwd user fails.


Fields changed

priority: major => critical

Thank you for the bug report.

The logs you pasted show that you are running abrt -- can you attach the core file? According to your logs it should be in /var/spool/abrt/ccpp-2012-03-20-15:11:34-833. If you run abrt-cli list, you'll the a report that includes all the crashes abrt is tracking.

owner: somebody => jhrozek

Fields changed

description: uname -r
3.2.10-3.fc16.x86_64

After a few minutes when sssd is launched :
systemctl restart sssd.service

Process are :
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
5663 ? R 0:00 /usr/libexec/sssd/sssd_be --domain LDAP --debug-to-files

The log says :
[root@lame4: 382] Mar 20 18:07:36 lame4 kernel: [11304.391716] sssd_be[5663]: segfault at 4000 ip 00007fc4188e64a2 sp 00007ffffbf0ce90 error 4 in sssd_be[7fc41888d000+75000]
Mar 20 18:07:36 lame4 abrtd: Directory 'ccpp-2012-03-20-18:07:36-5663' creation detected
Mar 20 18:07:36 lame4 abrt[5682]: Saved core dump of pid 5663 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-2012-03-20-18:07:36-5663 (16244736 bytes)
Mar 20 18:07:36 lame4 sssd[be[LDAP]]: Starting up
Mar 20 18:07:36 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:07:36-5663 (dup of ccpp-2012-03-20-15:04:40-828)

Process are :
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files

A few minutes later log says :
Mar 20 18:29:01 lame4 abrtd: Directory 'ccpp-2012-03-20-18:29:01-5630' creation detected
Mar 20 18:29:01 lame4 abrt[6320]: Saved core dump of pid 5630 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2012-03-20-18:29:01-5630 (1622016 bytes)
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:29:01-5630 (dup of ccpp-2012-03-20-15:11:34-833)

Process are :
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files

and getent passwd user doesn't work anymore

In a first time sssd_be segfaults and getent passwd user works,
ans in a second time sssd_nss try to start up and getent passwd user fails.

=> uname -r
3.2.10-3.fc16.x86_64

After a few minutes when sssd is launched :
systemctl restart sssd.service

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
5663 ? R 0:00 /usr/libexec/sssd/sssd_be --domain LDAP --debug-to-files
}}

The log says :
{{{
[root@lame4: 382] Mar 20 18:07:36 lame4 kernel: [11304.391716] sssd_be[5663]: segfault at 4000 ip 00007fc4188e64a2 sp 00007ffffbf0ce90 error 4 in sssd_be[7fc41888d000+75000]
Mar 20 18:07:36 lame4 abrtd: Directory 'ccpp-2012-03-20-18:07:36-5663' creation detected
Mar 20 18:07:36 lame4 abrt[5682]: Saved core dump of pid 5663 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-2012-03-20-18:07:36-5663 (16244736 bytes)
Mar 20 18:07:36 lame4 sssd[be[LDAP]]: Starting up
Mar 20 18:07:36 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:07:36-5663 (dup of ccpp-2012-03-20-15:04:40-828)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}

A few minutes later log says :
{{{
Mar 20 18:29:01 lame4 abrtd: Directory 'ccpp-2012-03-20-18:29:01-5630' creation detected
Mar 20 18:29:01 lame4 abrt[6320]: Saved core dump of pid 5630 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2012-03-20-18:29:01-5630 (1622016 bytes)
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:29:01-5630 (dup of ccpp-2012-03-20-15:11:34-833)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}
and getent passwd user doesn't work anymore

In a first time sssd_be segfaults and getent passwd user works,
ans in a second time sssd_nss try to start up and getent passwd user fails.

Fields changed

description: uname -r
3.2.10-3.fc16.x86_64

After a few minutes when sssd is launched :
systemctl restart sssd.service

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
5663 ? R 0:00 /usr/libexec/sssd/sssd_be --domain LDAP --debug-to-files
}}

The log says :
{{{
[root@lame4: 382] Mar 20 18:07:36 lame4 kernel: [11304.391716] sssd_be[5663]: segfault at 4000 ip 00007fc4188e64a2 sp 00007ffffbf0ce90 error 4 in sssd_be[7fc41888d000+75000]
Mar 20 18:07:36 lame4 abrtd: Directory 'ccpp-2012-03-20-18:07:36-5663' creation detected
Mar 20 18:07:36 lame4 abrt[5682]: Saved core dump of pid 5663 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-2012-03-20-18:07:36-5663 (16244736 bytes)
Mar 20 18:07:36 lame4 sssd[be[LDAP]]: Starting up
Mar 20 18:07:36 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:07:36-5663 (dup of ccpp-2012-03-20-15:04:40-828)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}

A few minutes later log says :
{{{
Mar 20 18:29:01 lame4 abrtd: Directory 'ccpp-2012-03-20-18:29:01-5630' creation detected
Mar 20 18:29:01 lame4 abrt[6320]: Saved core dump of pid 5630 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2012-03-20-18:29:01-5630 (1622016 bytes)
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:29:01-5630 (dup of ccpp-2012-03-20-15:11:34-833)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}
and getent passwd user doesn't work anymore

In a first time sssd_be segfaults and getent passwd user works,
ans in a second time sssd_nss try to start up and getent passwd user fails.

=> uname -r
3.2.10-3.fc16.x86_64

After a few minutes when sssd is launched :
systemctl restart sssd.service

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
5663 ? R 0:00 /usr/libexec/sssd/sssd_be --domain LDAP --debug-to-files
}}}

The log says :
{{{
[root@lame4: 382] Mar 20 18:07:36 lame4 kernel: [11304.391716] sssd_be[5663]: segfault at 4000 ip 00007fc4188e64a2 sp 00007ffffbf0ce90 error 4 in sssd_be[7fc41888d000+75000]
Mar 20 18:07:36 lame4 abrtd: Directory 'ccpp-2012-03-20-18:07:36-5663' creation detected
Mar 20 18:07:36 lame4 abrt[5682]: Saved core dump of pid 5663 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-2012-03-20-18:07:36-5663 (16244736 bytes)
Mar 20 18:07:36 lame4 sssd[be[LDAP]]: Starting up
Mar 20 18:07:36 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:04:40-828
Mar 20 18:07:36 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:07:36-5663 (dup of ccpp-2012-03-20-15:04:40-828)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5630 ? S 0:00 /usr/libexec/sssd/sssd_nss --debug-to-files
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}

A few minutes later log says :
{{{
Mar 20 18:29:01 lame4 abrtd: Directory 'ccpp-2012-03-20-18:29:01-5630' creation detected
Mar 20 18:29:01 lame4 abrt[6320]: Saved core dump of pid 5630 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2012-03-20-18:29:01-5630 (1622016 bytes)
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 sssd[nss]: Starting up
Mar 20 18:29:01 lame4 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Problem directory is a duplicate of /var/spool/abrt/ccpp-2012-03-20-15:11:34-833
Mar 20 18:29:01 lame4 abrtd: Deleting problem directory ccpp-2012-03-20-18:29:01-5630 (dup of ccpp-2012-03-20-15:11:34-833)
}}}

Process are :
{{{
5628 ? Ss 0:00 /usr/sbin/sssd -D -f
5631 ? S 0:00 /usr/libexec/sssd/sssd_pam --debug-to-files
}}}
and getent passwd user doesn't work anymore

In a first time sssd_be segfaults and getent passwd user works,
ans in a second time sssd_nss try to start up and getent passwd user fails.

This problem occured after the last yum update 5 days ago

---> Le paquet sssd.x86_64 0:1.6.4-1.fc16 sera mis à jour
---> Le paquet sssd.x86_64 0:1.8.1-7.fc16 sera la mise à jour
---> Le paquet sssd-client.x86_64 0:1.6.4-1.fc16 sera mis à jour
---> Le paquet sssd-client.x86_64 0:1.8.1-7.fc16 sera la mise à jour

Before this update everything was working well.

Attached core file and sssd.conf

_comment0: This problem occured after the last yum update

---> Le paquet sssd.x86_64 0:1.6.4-1.fc16 sera mis à jour
---> Le paquet sssd.x86_64 0:1.8.1-7.fc16 sera la mise à jour
---> Le paquet sssd-client.x86_64 0:1.6.4-1.fc16 sera mis à jour
---> Le paquet sssd-client.x86_64 0:1.8.1-7.fc16 sera la mise à jour

Before this update everything was well.

Attached core file and sssd.conf
=> 1332413101897099

This is the NSS backtrace.

#0  0x00007f80dceb9285 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f80dcebab9b in __GI_abort () at abort.c:91
#2  0x00007f80dfa74d85 in _dbus_abort () at dbus-sysdeps.c:94
#3  0x00007f80dfa6be31 in _dbus_warn_check_failed (format=
    0x7f80dfa7b010 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:289
#4  0x00007f80dfa542f4 in dbus_connection_send_with_reply (connection=0x0, message=0x7f80e1d184d0, pending_return=0x7fffbf631398, 
    timeout_milliseconds=150000) at dbus-connection.c:3392
#5  0x00007f80e07403b4 in sbus_conn_send (conn=<optimized out>, msg=0x7f80e1d184d0, timeout_ms=150000, reply_handler=
    0x7f80e0724a80 <sss_dp_internal_get_done>, pvt=0x7f80e1d2a3c0, pending=0x7f80e1d2ae90) at src/sbus/sssd_dbus_connection.c:711
#6  0x00007f80e0725a2f in sss_dp_internal_get_send (msg=0x7f80e1d184d0, dom=0x7f80e1cb70c0, key=0x7f80e1ce28d0, rctx=0x7f80e1cb38e0)
    at src/responder/common/responder_dp.c:653
#7  sss_dp_issue_request (mem_ctx=0x7f80e1ce29b0, rctx=0x7f80e1cb38e0, strkey=<optimized out>, dom=0x7f80e1cb70c0, 
    msg_create=<optimized out>, pvt=0x7f80e1d2b1d0, nreq=0x7f80e1ce84b0) at src/responder/common/responder_dp.c:292
#8  0x00007f80e0726b6d in sss_dp_get_account_send (mem_ctx=<optimized out>, rctx=0x7f80e1cb38e0, dom=0x7f80e1cb70c0, fast_reply=true, 
    type=SSS_DP_INITGROUPS, opt_name=<optimized out>, opt_id=0, extra=0x0) at src/responder/common/responder_dp.c:466
#9  0x00007f80e07097e4 in check_cache (dctx=0x7f80e1cbc520, nctx=<optimized out>, res=0x7f80e1ce8430, req_type=3, opt_name=
    0x7f80e1ce5ac0 "edoumith", opt_id=0, callback=0x7f80e070b370 <nss_cmd_initgroups_dp_callback>, pvt=0x7f80e1cbc520)
    at src/responder/nss/nsssrv_cmd.c:594
#10 0x00007f80e070adec in nss_cmd_initgroups_search (dctx=0x7f80e1cbc520) at src/responder/nss/nsssrv_cmd.c:3118
#11 0x00007f80e070b29c in nss_cmd_initgroups (cctx=0x7f80e1d29d80) at src/responder/nss/nsssrv_cmd.c:3247
#12 0x00007f80e071fe36 in client_recv (cctx=0x7f80e1d29d80) at src/responder/common/responder_common.c:180
#13 client_fd_handler (ev=<optimized out>, fde=<optimized out>, flags=1, ptr=<optimized out>)
    at src/responder/common/responder_common.c:218
#14 0x00007f80e02d0a68 in epoll_event_loop (tvalp=0x7fffbf6317d0, std_ev=0x7f80e1cad3f0) at ../tevent_standard.c:326
#15 std_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../tevent_standard.c:565
#16 0x00007f80e02cdbc0 in _tevent_loop_once (ev=0x7f80e1cad330, location=0x7f80e0763d01 "src/util/server.c:572") at ../tevent.c:504
#17 0x00007f80e02cdd4b in tevent_common_loop_wait (ev=0x7f80e1cad330, location=0x7f80e0763d01 "src/util/server.c:572") at ../tevent.c:605
#18 0x00007f80e0744273 in server_loop (main_ctx=0x7f80e1cae4a0) at src/util/server.c:572
#19 0x00007f80e070153a in main (argc=2, argv=<optimized out>) at src/responder/nss/nsssrv.c:368

Can you also attach the sssd_be backtrace/coredump?

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.8.2 (LTM)

Fields changed

summary: sssd-1.8.1-7.fc16 sssd_be and sssh_nss crash segfault => sssd-1.8.1-7.fc16 sssd_be and sssd_nss crash segfault

The sssd_be crash was already fixed upstream in 5b9c04e. The fix is also present in sssd-1.8.1-8 which is in updates-testing now. Can you try that package and see if it resolves your problem?

The sssd_nss crash still needs to be investigated, though.

status: new => assigned

I reproduced the issue. Changing the summary to more accurately reflect the bug.

summary: sssd-1.8.1-7.fc16 sssd_be and sssd_nss crash segfault => sssd_nss crashes on request when no back end is running

Fields changed

patch: 0 => 1

Fixed by:
- 6e8b4d4 (master)
- 5ee1287 (sssd-1-8)

resolution: => fixed
status: assigned => closed

Metadata Update from @dax:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.8.2 (LTM)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2312

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata