#1270 sssd_nss crashes on request when no back end is running
Closed: Fixed None Opened 7 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)

2 years ago

Login to comment on this ticket.

Metadata