On Tue, Dec 04, 2012 at 02:38:34PM -0500, Simo Sorce wrote:
On Tue, 2012-12-04 at 14:31 -0500, Qing Chang wrote:
> On 04/12/2012 2:19 PM, Simo Sorce wrote:
> > On Tue, 2012-12-04 at 13:11 -0500, Dmitri Pal wrote:
> >>> A "service sssd restart" "fix" the problem...
> >>>
> >>> I am thinking of running a cron job of above every 10 minutes to
> >> work
> >>> around
> >>> the problem while it is being troubleshoot. Is it a bad idea?
> > Well every 10 min. seem a bit too much, but I guess it depends how long
> > your user is willing to wait when it breaks :-/
> >> This thread reminded me of the following thread
> >>
https://lists.fedorahosted.org/pipermail/sssd-devel/2011-September/007058...
> >
> > Yes Dmitri, this is very similar.
> >
> > Qing,
> > do you happen to have the provider logs as well ?
> >
> > It seemed confined to the nss responder, but it may be an actual
> > provider issue after all, seem like the provider is deleting the user
> > from the cache from time to time, and it shouldn't.
> >
The provider has no means of deleting a user from cache, in the current
model, the responders are pure "readers" and only the back ends are
"writers".
> > Simo.
> I am sorry, but what is the provider log?
Oh sorry, I should have been more specific, the provider log is the log
file named after your domain sssd_my.domain.name.log which contains logs
about the connection to the server and might explain what error the
provider got when it decided to go oflline (which may have also caused
the incorrect deletion of the user from the cache).
I agree the issue seems to be on the provider side, though. For some
reason, the provider is going offline and it shouldn't.
What puzzles me is that Qing described the failing case as "open
Thunderbird". I don't quite understand how that could fail except for a
timeout? We should still return data from cache..