On (29/04/16 12:58), Jakub Hrozek wrote:
On Fri, Apr 29, 2016 at 12:15:46PM +0200, Lukas Slebodnik wrote:
> On (29/04/16 10:38), Jakub Hrozek wrote:
> >On Fri, Apr 29, 2016 at 10:35:54AM +0200, Pavel Březina wrote:
> >> On 04/29/2016 10:30 AM, Ondrej Valousek wrote:
> >> > Hi List,
> >> >
> >> > [root@machine ~]# sss_cache -g mpeg2
> >> >
> >> > No cache object matched the specified search
> >> >
> >> > [root@machine ~]# getent -s sss group mpeg2
> >> >
> >> > mpeg2:*:139:
> >> >
> >> > Is this normal behavior? I have deleted mpeg2 group recently…
> >> >
> >> > Only after I do ‘sss_cache –G’ it goes away eventually….
> >> >
> >> > Thanks,
> >> >
> >> > Ondrej
> >>
> >> Hi,
> >> so if I understand it correctly the group is still in cache but sss_cache
> >> won't invalidate it?
> >>
> >> What version of sssd do you use? And what can we get from:
> >> sss_cache --debug 0x3ff0 -g mpeg2
> >
> >I guess the group can already be removed from the ldb cache but can
> >still be present in the memory cache..
>
> Memory cache is invalidated after calling sss_cache.
>
> Wen have an integration test fot it :-)
But in this test the sss_cache tool said no cache object matched, do we
invalidate the memory cache even in that scenario?
I missed that important point;
and answer is NO
Fell free to file a bug.
BTW "sss_cache –G" works because sysdb_search_groups will not return ENOENT
and therefore memory cache was invalidated.
LS