Thankyou Sumit.
I will test with and without tokengroups.

However, please bear with me.  Could you make it more clear what is happening here

a) an initial run of 'groups abc' takes some time to complete.
    OK, that is fine - we know information must be fetched from Active Directory

b) the next time 'groups abc' is run it returns in less thna 1 second.
    OK - I think this mus tbe using cached information

c) after a certain amount of time 'groups abc'  again takes a long time to return

The documentation says that after  refresh_expired_interval a BACKGROUND refresh is run.
Surely then you always have an up to date set of cached information?

I think what you are saying is that the groupmemberships are NOT refreshed in the background.

If so, would it be the useful to set entry_cache_timeout to a very high level?

To explain, we work in a windowing environment (LightDM). When a window is opened this can take a long time,
as 'groups abc' is run as part of the login. We dont want  a user to have random times when opening a window will seem to freeze or take a long time.


















On 4 July 2018 at 16:00, Sumit Bose <sbose@redhat.com> wrote:
On Wed, Jul 04, 2018 at 11:30:21AM +0200, John Hearns wrote:
> One thing I do note. I have reduced refresh_expired_interval to 40 seconds,
> which is clearly a ridiculously low time.
> However when I look at the cached information I always see Initgroups
> expiration time:Expired
>
> I am not sure what this means.
>
> root@ibis:~# sssctl user-show abc
> Name: abc
> Cache entry creation date: 06/27/18 17:09:58
> Cache entry last update time: 07/04/18 11:28:16
> Cache entry expiration time: 07/04/18 11:29:16
> Initgroups expiration time: Expired
> Cached in InfoPipe: No
>

Yes, this is expected because the groupmemberships are not updated here
because it would be too expensive. But if you use the AD provider with
tokenGroups enabled (the default) it should help nonetheless because all
groups in the cache should be valid and after the single tokenGroups
LDAP request the user "just" has to be added to all the group it is a
member of.

Please let me know if it still needs 20s or more to update the group
memberships with tokenGroups enabled if all groups are still valid.

bye,
Sumit

>
>
>
> On 4 July 2018 at 11:01, John Hearns <hearnsj@googlemail.com> wrote:
>
> > Thankyou Sumit. I think you might be trying to tel lme something with the
> > debug_level=6   :-)
> >
> > On 4 July 2018 at 09:04, Sumit Bose <sbose@redhat.com> wrote:
> >
> >> On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
> >> > I have an AD setup where users can be a member of perhaps 130 groups.
> >> > When I run 'groups jbloggs' this can take 90 seconds or even longer.
> >> > I have reduced that time to perhaps 20 seconds by setting
> >> > ignore_group_members = TRUE
> >> >
> >> > Once the information is cached the groups command returns in less that
> >> one
> >> > second.
> >> > However, after a length of time the cache seems to be invalidated and
> >> the
> >> > information is fetched again from the server, taking 20 seconds again.
> >> > The cacheing parameters are set to:
> >> >
> >> > entry_cache_timeout = 5400
> >> > entry_cache_user_timeout = 5400
> >> > entry_cache_group_timeout = 5400
> >> > refresh_expired_interval = 4000
> >> >
> >> > Surely this means that after 4000 seconds the user and group
> >> information is
> >> > refreshed in the background.
> >> > So a user running the groups command would always see freshly cached
> >> values?
> >>
> >> With 'debug_level=6' or higher in the [domain/...] section of sssd.conf
> >> you
> >> should be able to see messages like 'Refreshing <username> in domain
> >> <domainname>' in domain log file when is refresh task is running.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > Clearly I am not understanding something here.
> >>
> >> > _______________________________________________
> >> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> >> > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> >> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> > List Archives: https://lists.fedoraproject.or
> >> g/archives/list/sssd-users@lists.fedorahosted.org/message/M4
> >> R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
> >> _______________________________________________
> >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> >> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: https://lists.fedoraproject.or
> >> g/archives/list/sssd-users@lists.fedorahosted.org/message/GY
> >> L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
> >>
> >
> >

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/P3WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/RUJIULW2YG7NJZPU64NHTCR2GSAIQZE4/