SSSD / sssd

#205 sssd crash after suspend
Closed: Fixed Opened by villeys.

Closed: Fixed
Reopen Issue

sssd git version 2009-09-24 plus this patch
https://fedorahosted.org/pipermail/sssd-devel/2009-September/000686.html

Things seem better now. Previously resuming from suspend and having sssd crash, only sssd main and sssd_dp processes were running.

Now I tried three times suspending. Computer was many hours in suspend. In one of the tests I got sssd crash. There is no core or debug.log :-( but process list available. Only sssd_nss has crashed.

When I resume from suspend gnome-screensaver tries to find credentials for the user that has logged in right away because screen is locked. Maybe it would be worth checking if sssd_nss has similar problem as fixed by the patch in the link.

[root@host ~]# ps -aux|grep sssd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root      3358  0.0  0.0 139600  1872 ?        Ss   18:01   0:03 /usr/sbin/sssd
-D
root      3367  0.0  0.1 137480  2556 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_dp -d 0
root      3374  0.0  0.0      0     0 ?        Z    18:01   0:00 [sssd_nss] <defunct>
root      3375  0.0  0.1 140484  3612 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_pam -d 0
root      3376  0.0  0.2 147616  5652 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_be -d 0 --domain LDAP
root      6719  0.0  0.0  61176   720 tty1     R+   19:22   0:00 grep sssd
[root@host ~]#

Maybe this process list is better aligned:

[root@host ~]# ps -aux|grep sssd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root      3358  0.0  0.0 139600  1872 ?        Ss   18:01   0:03 /usr/sbin/sssd
-D
root      3367  0.0  0.1 137480  2556 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_dp -d 0
root      3374  0.0  0.0      0     0 ?        Z    18:01   0:00 [sssd_nss] <defunct>
root      3375  0.0  0.1 140484  3612 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_pam -d 0
root      3376  0.0  0.2 147616  5652 ?        S    18:01   0:00 /usr/libexec/sssd/sssd_be -d 0 --domain LDAP
root      6719  0.0  0.0  61176   720 tty1     R+   19:22   0:00 grep sssd
[root@host ~]#

Now I got the same result after unhooking the laptop from docking station. As user I do:

[username@host ~]$ ps -aux|grep -i sssd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root      3357  0.0  0.0 139620  1840 ?        Ss   11:43   0:05 /usr/sbin/sssd -f -D -d 5
root      3366  0.0  0.1 137496  2168 ?        S    11:43   0:00 /usr/libexec/sssd/sssd_dp -d 5 --debug-to-files
root      3381  0.0  0.0      0     0 ?        Z    11:43   0:00 [sssd_nss] <defunct>
root      3384  0.0  0.1 135604  2272 ?        S    11:43   0:00 /usr/libexec/sssd/sssd_pam -d 5 --debug-to-files
root      3385  0.0  0.2 147636  5248 ?        S    11:43   0:00 /usr/libexec/sssd/sssd_be -d 5 --debug-to-files --domain LDAP
root      9213  0.0  0.0  58940   524 pts/2    S+   14:14   0:00 tail -f /var/log/sssd/sssd.log
811       9332  0.0  0.0  61176   724 pts/4    R+   14:17   0:00 grep -i sssd
[username@host ~]$

..and it takes a long time to complete, maybe couple of minutes. While waiting for the command to complete as root I get instantly:

[root@host ~]# ps -ef|grep -i sssd
root      3357     1  0 11:43 ?        00:00:05 /usr/sbin/sssd -f -D -d 5
root      3366  3357  0 11:43 ?        00:00:00 /usr/libexec/sssd/sssd_dp -d 5 --debug-to-files
root      3381  3357  0 11:43 ?        00:00:00 /usr/libexec/sssd/sssd_nss -d 5 --debug-to-files
root      3384  3357  0 11:43 ?        00:00:00 /usr/libexec/sssd/sssd_pam -d 5 --debug-to-files
root      3385  3357  0 11:43 ?        00:00:00 /usr/libexec/sssd/sssd_be -d 5 --debug-to-files --domain LDAP
root      9213  9173  0 14:14 pts/2    00:00:00 tail -f /var/log/sssd/sssd.log
username   9332  9301  0 14:17 pts/4    00:00:00 grep -i sssd
root      9412  9373  0 14:18 pts/5    00:00:00 grep -i sssd

This is with sssd-0.6.0

version: 0.5.0 => 0.6.0

This seems to be a configuration error on the system. I have overlapping id ranges.
defining
filter_users=root,overlappinguser
filter_groups=root,overlappinggroup

seems to fix the issue.

priority: major => minor

I was wrong, defining filterusers etc does not fix the issue.

priority: minor => major

Unplugging the network cable is enough to reproduce the issue.

login with account on native ldap, unplug network cable, wait 20secs or more, do: ps -aux

and you should see the issue

Fields changed

description: sssd git version 2009-09-24 plus this patch
https://fedorahosted.org/pipermail/sssd-devel/2009-September/000686.html

Things seem better now. Previously resuming from suspend and having sssd crash, only sssd main and sssd_dp processes were running.

Now I tried three times suspending. Computer was many hours in suspend. In one of the tests I got sssd crash. There is no core or debug.log :-( but process list available. Only sssd_nss has crashed.

When I resume from suspend gnome-screensaver tries to find credentials for the user that has logged in right away because screen is locked. Maybe it would be worth checking if sssd_nss has similar problem as fixed by the patch in the link.

[root@host ~]# ps -aux|grep sssd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root 3358 0.0 0.0 139600 1872 ? Ss 18:01 0:03 /usr/sbin/sssd
-D
root 3367 0.0 0.1 137480 2556 ? S 18:01 0:00 /usr/libexec/sssd/sssd_dp -d 0
root 3374 0.0 0.0 0 0 ? Z 18:01 0:00 [sssd_nss]
root 3375 0.0 0.1 140484 3612 ? S 18:01 0:00 /usr/libexec/sssd/sssd_pam -d 0
root 3376 0.0 0.2 147616 5652 ? S 18:01 0:00 /usr/libexec/sssd/sssd_be -d 0 --domain LDAP
root 6719 0.0 0.0 61176 720 tty1 R+ 19:22 0:00 grep sssd
[root@host ~]#
=> sssd git version 2009-09-24 plus this patch
https://fedorahosted.org/pipermail/sssd-devel/2009-September/000686.html

Things seem better now. Previously resuming from suspend and having sssd crash, only sssd main and sssd_dp processes were running.

Now I tried three times suspending. Computer was many hours in suspend. In one of the tests I got sssd crash. There is no core or debug.log :-( but process list available. Only sssd_nss has crashed.

When I resume from suspend gnome-screensaver tries to find credentials for the user that has logged in right away because screen is locked. Maybe it would be worth checking if sssd_nss has similar problem as fixed by the patch in the link.
{{{
[root@host ~]# ps -aux|grep sssd
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root 3358 0.0 0.0 139600 1872 ? Ss 18:01 0:03 /usr/sbin/sssd
-D
root 3367 0.0 0.1 137480 2556 ? S 18:01 0:00 /usr/libexec/sssd/sssd_dp -d 0
root 3374 0.0 0.0 0 0 ? Z 18:01 0:00 [sssd_nss]
root 3375 0.0 0.1 140484 3612 ? S 18:01 0:00 /usr/libexec/sssd/sssd_pam -d 0
root 3376 0.0 0.2 147616 5652 ? S 18:01 0:00 /usr/libexec/sssd/sssd_be -d 0 --domain LDAP
root 6719 0.0 0.0 61176 720 tty1 R+ 19:22 0:00 grep sssd
[root@host ~]#
}}}
milestone: SSSD 1.0 => SSSD 0.6.1
owner: somebody => simo
priority: major => critical
tests: 0 => 1

if you unplug the network and do 'id somenonexistentusername'

sssd_nss never returns anything. When it timeouts, sssd_nss is restarted for some reason. While the sssd_nss is waiting for something, the sssd process pinging nss responds ok.

(1254241223) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1].
(1254241223) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(1254241223) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [joohas546] from [<ALL>]
(1254241223) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [joohas546@LDAP]
(1254241223) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [LDAP][1][core][name=joohas546]
(1254241235) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(1254241235) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1].
(1254241235) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(1254241235) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [joohas5466545] from [<ALL>]
(1254241235) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [joohas5466545@LDAP]
(1254241235) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [LDAP][1][core][name=joohas5466545]
(1254241373) [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (2): Unable to get information from Data Provider
Error: 2, 62, Request timed out
Will try to return what we have in cache
(1254241373) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No matching domain found for [joohas546], fail!
(1254241373) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No results for getpwnam call
(1254241374) [sssd[nss]] [server_setup] (3): CONFDB: /var/lib/sss/db/config.ldb
(1254241374) [sssd[nss]] [confdb_get_domain_internal] (1): No enumeration for [LDAP]!
(1254241374) [sssd[nss]] [sbus_init_connection] (5): Adding connection 1FD88410
(1254241374) [sssd[nss]] [monitor_common_send_id] (4): Sending ID: (nss,1)
(1254241374) [sssd[nss]] [sbus_init_connection] (5): Adding connection 1FD89CE0
(1254241374) [sssd[nss]] [dp_common_send_id] (4): Sending ID to DP: (2,1,NSS,)
(1254241374) [sssd[nss]] [sysdb_domain_init_internal] (5): DB File for LDAP: /var/lib/sss/db/cache_LDAP.ldb
(1254241374) [sssd[nss]] [ldb] (3): asq: Unable to register control with rootdse!
(1254241374) [sssd[nss]] [sss_process_init] (1): Responder Initialization complete
(1254241374) [sssd[nss]] [nss_process_init] (1): NSS Initialization complete
(1254241374) [sssd[nss]] [id_callback] (4): Got id ack and version (1) from DP
(1254241374) [sssd[nss]] [id_callback] (4): Got id ack and version (1) from Monitor

steps to reproduce:

service sssd stop
killall sssd
killall sssd_be
killall sssd_dp
killall sssd_nss
killall sssd_pam
rm -f /var/lib/sss/db/*
service sssd start
# this works
id somenonexistentusername
#unplug the network
#this does not anymore 
id somenonexistentusername2

The request goes to data provider but:

(1254242474) [sssd[dp]] [dp_get_account_info] (4): Got request for [LDAP][1][core][name=asoniaa]
(1254242474) [sssd[dp]] [dp_send_acct_req] (4): Sending request for [1][core][name=asoniaa]
(1254242624) [sssd[dp]] [sbus_dispatch] (3): Connection is not open for dispatching.
(1254242625) [sssd[dp]] [sbus_server_init_new_connection] (5): Entering.
(1254242625) [sssd[dp]] [sbus_server_init_new_connection] (5): Adding connection 0x53e9f40.
(1254242625) [sssd[dp]] [sbus_init_connection] (5): Adding connection 53E9F40
(1254242625) [sssd[dp]] [sbus_server_init_new_connection] (5): Got a connection
(1254242625) [sssd[dp]] [dp_client_init] (4): Set-up DP ID timeout [0x53ebcf0]
(1254242625) [sssd[dp]] [client_registration] (4): Cancel DP ID timeout [0x53ebcf0]
(1254242625) [sssd[dp]] [client_registration] (4): Added Frontend client [NSS]

It seems that sssd[be[LDAP]]] does not notice that we are offline

There some 10 minute timeouts in server/providers/ldap/sdap_async.c
in ldap_search_ext functions

If you change them to something like few seconds 'id somenonexitentuser' command does not take all day right after unplugging the network.. The sssd_nss service still does a restart.

The patch that was merged to master works. Also it is now possible to set the timeout in configuration. ldap provider does a restart when timeout is reached, don't know if it should do that or not.

(1254471723) [sssd[be[LDAP]]] [main] (1): Backend provider (LDAP) started!

But for me it looks like the bug is gone. I'll do another ticket if I find something more.

Fixed in 4e0314ecad0fb649bcc2d6384a84ae818ef7c972

fixedin: => 0.6.1
resolution: => fixed
status: new => closed

Fields changed

tests: 1 => 0
testsupdated: 0 => 1

Fields changed

rhbz: => 0

Metadata Update from @villeys:
- Issue assigned to simo
- Issue set to the milestone: SSSD 0.6.1

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/1247

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.
Metadata
None
None
None
Low
defect
SSSD
0.6.0
1
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.