[SSSD-users] Unable to kill SSSD processes

Dmitri Pal dpal at redhat.com
Tue Jan 6 23:27:54 UTC 2015


On 01/06/2015 05:35 PM, Lukas Slebodnik wrote:
> On (06/01/15 14:17), Patrick Mayo wrote:
>> Hello, Everyone!
>>
>> I'm encountering an interesting issue on one of our production systems.
>> Because it's production, I'm trying not to reboot the system if not needed.
>> The core issue being that RDS ldap users are currently unable to log into
>> this box at all due to SSSD being in some sort of funk state. The
>> /var/log/secure file shows a lot of pam_sss(crond:session): Request to sssd
>> failed. Connection refused errors.
>>
>> A status check against the service shows that it is running, but attempting
>> a stop results in a failed attempt.
>>
>> [root at server~]# service sssd status
>> sssd (pid 13504) is running...
>> [root at server~]# service sssd stop
>> Stopping sssd:                                             [FAILED]
>>
>> ps shows that the following results and attempting to kill -9 any of them
>> doesn't seem to work. No error is reported, the processes just persist past
>> the kill -9 order.
> That's weird.

I have seen something like this many years ago on Solaris when the 
process is actually gone but parent and OS thinks it is still there.
I think it was caused by a memory violation inside atexit() callback or 
something like.

>
>> [root at server~]# ps aux | grep sss | grep -v grep
>> root      7532  0.0  0.0 150828  2168 ?        D    Jan03   0:00
>> /usr/libexec/sssd/sssd_nss -d 0 --debug-to-files
>> root     13504  0.1  0.0  95808  2928 ?        D    Jan05   1:44
>> /usr/sbin/sssd -f -D
>> root     16390  0.0  0.0 150784  2172 ?        D    Jan03   0:00
>> /usr/libexec/sssd/sssd_pam -d 0 --debug-to-files
>> root     24156  0.0  0.0 179396  5428 ?        D     2014   8:21
>                                                 ^^^
>                         It means:  D    uninterruptible sleep (usually IO)
>> Also, whenever I try to do anything with the /var/lib/sss/db/ directory or
>> the files within it, the console becomes unresponsive. This even happens if
>> I ls the path and ctrl+c won't break commands issued to this location and
>> the console locks up.
>> I'm still new to strace, but I used that while trying to ls
>> /var/lib/sss/db/ and the results stopped with getdents(3,  being the final
>> entry and the same unresponsive console issue as before. I also setup
>> strace to monitor the pids of the sssd related processes with commands
>> similar to the one below, but the output files aren't being populated with
>> anything.
> It can be some problem with filesystem where /var/lib/sss/db/ is stored.
> getdents is "get directory entries" and it is not related to sssd.
>
>> strace -s 2000 -o /path/to/file/out.txt -fp 12345 &
>>
>> /var/log/messages doesn't really seem to include anything that relates to
>> this issue.
>>
>> /var/log/sssd/sssd_nss.log and /var/log/sssd/sssd_pam.log are both empty
>> with no archives
>>
>> /var/log/sssd/sssd_[domain].log has a timestamp of Jan 4th, but is empty.
>> The previous archived log shows the following entries which occurred the
>> same day that ps shows some of the sssd processes started on.
> Debuging is not enabled by default. You can change debug level on the fly
> with command line utility sss_debuglevel or you can modify sssd configuration
> file sssd.conf. man sssd.conf -> debug_level
>
> LS
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



More information about the sssd-users mailing list