Title: #5450: kcm: add support for kerberos tgt renewals
> It's not sleeping, it still spins in tevent loop doing stuff
which may have a negative impact on battery.
That's exactly my question: what is it doing? IIUC, it should be sleeping on
`epoll()` (say 99.999% of the time)
If it actually does something useful, it means process would have to be socket activated
otherwise which is much more expensive than awaking from epoll().
If it doesn't do anything usefull, then what is it doing?
epoll is just one of the tevent mechanisms, there is much more to it. It does not check
only epoll, but also go into internal structures to watch for signals and to trigger timed
events and tevent reqs. But lets not dive into it, I formulated my previous answer wrongly
and made battery life a stronger point then I meant. If this was the reason to keep it as
short lived process it is certainly something then needs to be measured.
My point was that lots of logic that Justin introduced would not be necessary.
> Ah, I missed the last patch: `KCM: Disable responder idle
timeout with renewals`. So it will work correclty. But I wonder if it would be better to
keep the idle timeout enabled. What we could do is to make systemd timer send a
SSSD-specific KCM op code periodically and renew the tickets per-request. This would also
simplify the logic by a lot since you would not have to keep the hash table and timers.
I'm fine with this approach, but if the systemd timer file is installed conditionally
at build time(if KCM renewals are built), then what interval value, i.e. amount of time
that KCM wakes up to attempt renewals, should we set in the systemd timer file? Currently
the renew interval is defined with the `krb5_renew_interval` option in sssd.conf. This is
an important consideration because if the renewal interval is too high then we could miss
renewing tickets that have already expired, too low and it may add unnecessary KCM load.
I suppose the other side effect is that falllback to `auth_provider=krb5` renew config
options would no longer work.
Fair point. Let's continue with this patch set as is. Since SSSD is not currently
relying that much on systemd it is probably a better choice. We can revisit this if we
ever switch from monitor to systemd.
See the full comment at https://github.com/SSSD/sssd/pull/5450#issuecomment-800159007