URL:
https://github.com/SSSD/sssd/pull/511
Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented:
"""
@simo5, please, bear with me here.
I'm a little bit confused about tevent_ops/tevent_signal/tevent_queue. Taking a look
at tevent_context, there's no API to easily check whether there are pending operations
or not. However, I can see a non-public API that could be used for that:
`tevent_common_check_signal` (or at least I think so).
Wouldn't be the case to have `tevent_common_check_signal` exposed on samba side and
just add the following patch to the responder's common code?
```
--- a/src/responder/common/responder_common.c
+++ b/src/responder/common/responder_common.c
@@ -374,7 +374,7 @@ static void responder_idle_handler(struct tevent_context *ev,
goto end;
}
- if ((now - rctx->last_request_time) > rctx->idle_timeout) {
+ if (tevent_common_check_signal == 0 && (now - rctx->last_request_time)
> rctx->idle_timeout) {
/* This responder is idle. Terminate it */
DEBUG(SSSDBG_TRACE_INTERNAL,
"Terminating idle responder [%p]\n", rctx);
```
Does this make sense?
Another question that I have is why tevent_context does not have a tevent_queue structure
that we could just do a `tevent_queue_length` and be happy? :-)
Again, please, keep in mind that I may be firing non-sense questions due to lack of
technical knowledge on samba side (and here I'll be more than happy to learn more from
you).
"""
See the full comment at
https://github.com/SSSD/sssd/pull/511#issuecomment-377480814