URL:
https://github.com/SSSD/sssd/pull/5552
Title: #5552: files: split update into batches
sumit-bose commented:
"""
Hi,
I think the latest issues you've found are not strictly related to the patches. The
reason is that if there are many users and groups in the cache the `sss_cache -UG` needs
more time to invalidate all users and groups. With 5000 users and the related primary
groups it looks like `sss_cache` runs for more then 1s even if all entries are already
invalidated. But this means that the next `userdel` command is called more than 1s after
the last `userdel` which means that it is called while a refresh is running. This is no
issue for the `userdel` command itself, but `userdel` will call `sss_cache` which will try
to modify the cache which is locked by the transaction covering the refresh. So
`sss_cache` has to wait until the refresh is finished which might take some time. For the
next `userdel` call the same happens again.
It might be possible to mitigate this by increasing the initial delay before the refresh
starts (`struct timeval delay` in `check_state()`) but this will delay the refresh for all
other cases as well.
Another way might be to speed up the refresh by not deleting and adding everything from
scratch but with a diff like approach. But as discussed earlier this should be part of a
PR.
It might also be possible to modify `sss_cache` so that it e.g. only sends a command to
SSSD and not tries to modify the caches on its own.
bye,
Sumit
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5552#issuecomment-872351523