[SSSD] Is there a way to check last time SSS cache was updated?

Viviano, Brad Viviano.Brad at epa.gov
Fri Jun 27 15:21:33 UTC 2014


Michal,
    I can try.  Is there a way to increase debugging level without restarting the service (i.e. command channel or signal I can send to sssd).  I can't really afford the disk space to leave debug set so high on all my systems hoping it might happen on one of them and if I have to restart sssd, the problem corrects itself.

    -Brad

===================================================
Brad Viviano
High Performance Computing & Scientific Visualization
Lockheed Martin, Supporting the EPA
Research Triangle Park, NC
919-541-2696

HSCSS Task Order Lead - Ravi Nair
919-541-5467 - Nair.Ravi at epa.gov
High Performance Computing Subtask Lead - Durward Jones
919-541-5043 - Jones.Durward at epa.gov
Environmental Modeling and Visualization Lead - Heidi Paulsen
919-541-1834 - Paulsen.Heidi at epa.gov

________________________________________
From: sssd-devel-bounces at lists.fedorahosted.org <sssd-devel-bounces at lists.fedorahosted.org> on behalf of Michal Židek <mzidek at redhat.com>
Sent: Friday, June 27, 2014 9:42 AM
To: Development of the System Security Services Daemon
Subject: Re: [SSSD] Is there a way to check last time SSS cache was updated?

On 06/27/2014 10:11 AM, Jakub Hrozek wrote:
> On Thu, Jun 26, 2014 at 04:56:21PM +0000, Viviano, Brad wrote:
>> Hello,
>>
>>      I'm running SSSd under RHEL6 using Redhat's standard RPM's (sssd-1.9.2-129). In the last two weeks I've had on two different systems develop a situation where sssd wasn't updating its cache, so new users and group updates from LDAP where not getting picked up. SSSd was still running, but using "getent" wouldn't return information about the user and they could not login. Once I diagnosed the problem, I restarted sssd and it immediately picked up the changes and everything was fine.
>>
>>      Which leads me to my question. Is there a way to determine the last time the sss cache was updated successfully for a particular domain? I'd like to write a Nagios plugin that could alert me if sssd gets stuck again. I didn't know if it was as simple as checking the timestamp on the associated "cache_DOMAIN.ldb" file or not. I didn't think to check the timestamp on the two systems that had problems, I was too focused on resolving the issue.
>>
>>
>>      Thanks,
>>
>>              -Brad Vivaino
>
> Not an easy one, currently.
>
> We have a ticket open to develop a 'sssctl' tool, maybe raising the
> priority of this work with your Red Hat support contacts would help:
> https://fedorahosted.org/sssd/ticket/385
>
> What you can do, though is:
> 0) yum install ldb-tools
> 1) Invalidate a user using the sss_cache tool
> 2) Check that the cache expiry status (dataExpireTimeStamp), it should
> be set to 1 now
>
> ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username dataExpireTimestamp
>
> 3) Request the user again
> getent passwd $username
>
> 4) Check the cache expiry again. If sssd was online when the request was
> made, the dataExpireTimestamp would be set to a sensible value.

If outdated data was taken from the cache when users
tried to log in, then SSSD was most likely offline
(SSSD never goes for the cached data during login
operation when it is online).

The reason for SSSD going offline might be the real
problem here. If you can reproduce the problem, could
you send logs (with debug level 7 or higher)?

Michal
_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list