URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: opened
PR body: """ Firstly, I'd like to make it **explicit** that this PR is **missing tests**, but I won't write them down till we have an agreement whether the proposed patches do look right/good.
Basically, while trying to reproduce https://pagure.io/SSSD/sssd/issue/3470 I've noticed that both secrets and kcm responders were going down due to the responder_idle_timeout expiring ... even with a lot of activities happening on them.
Does this approach look right? If yes, then, what would be the easiest way to test: - A responder actually goes down after x seconds; - Any activity on that responder will make the responder alive for more x seconds; """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ The fix is correct, thank you. But I wonder if we could improve this even a bit more. An easy way would be to split the connection timeout reset from `client_fd_handler` and reuse it in secrets and KCM. A more involved way, looking at how the `client_fd_handler` differs from secrets and kcm handler would be to instead of letting the caller set the `cctx->cfd_handler` let them only set the send and recv functions. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-363799870
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ I'm fine with those changes proposed. I'm adding the "Changes Requested" label and will be working on them.
As I don't think there's an easy way to test the responder idle timeout with our infra (and please, correct me if I'm mistaken) I'd like to ask whether we can have an upstream (that should be cloned to downstream) issue to refer these patches to and also to ensure they're covered by at least one of our tests ... does that make sense, @jhrozek? """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-363802161
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ We should have at least a ticket upstream. About tests, I wonder if we could set a low idle timeout, spawn the secrets or kcm responder and then check if it shuts down? Or do we enforce some minimal idle timeout that would make it unreasonable to test this with integration checks? """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-363816508
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ Okay, @jhrozek, your suggestion works. I'll update the patch set soon. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-363894796
URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ Patch set has been updated. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-364066876
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ sorry for the delay, the patches look OK now code-wise, I just need a bit more time to do more careful testing (aka I'd like to run the code on my laptop for a day or two to make sure if I catch any bug before our users do..also, I've been able to randomly reproduce the bug on my laptop.) """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-368658242
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ Actually, I have some more questions about the code: - why do the first two patches fix code that the subsequent patches refactor? Is it to make it clear where the issue is? Or did you consider backporting the first two patches to some older branches? - I see you added a new dependency python-psutils but only is_running() is used. Have you considered implementing a simple version of is_running internally? I think just checking for the same PID and the same executable and the same running time would be quite OK. - The tests you added are nice and it's really great that the coverage is on par with the code, but the tests are also slow. 90 and 60 seconds respectively is quite a lot. I wonder if you could send a mail to sssd-devel about this in case anyone would be irritated by slow tests. I think it doesn't matter how long Jenkins is chewing the tests, but if I was hacking on sssd-secrets, I wouldn't like to wait for over two minutes for tests to complete the `make intgcheck-run`. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-372472897
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """
why do the first two patches fix code that the subsequent patches refactor? Is it to make it clear where the issue is? Or did you consider backporting the first two patches to some older branches?
It was to make clear that the issues has been fixed in the first two patches. The rest of the series is "just" refactoring the code. IMO it's just easier for the "future fidencio" to bisect the some issue and understand why things where done in this way in the past.
So, answering your second question ... No, when I wrote the patches I didn't think of backporting them to any specific branch ... but had in mind that distros could choose to backport just those 2 patches instead of the whole refactor.
I see you added a new dependency python-psutils but only is_running() is used. Have you considered implementing a simple version of is_running internally? I think just checking for the same PID and the same executable and the same running time would be quite OK.
python-psutils was there for free (on all supported OSes in our CI) and that's the reason I've decided to use that.
IMO the effort of maintaining our on version of "is_running" (our anything else already provided by a package that is there from el6 to latest fedora) is not worth it, but if that's your preference ... I can write up my own and use it.
The tests you added are nice and it's really great that the coverage is on par with the code, but the tests are also slow. 90 and 60 seconds respectively is quite a lot. I wonder if you could send a mail to sssd-devel about this in case anyone would be irritated by slow tests. I think it doesn't matter how long Jenkins is chewing the tests, but if I was hacking on sssd-secrets, I wouldn't like to wait for over two minutes for tests to complete the make intgcheck-run.
I'll send an email to the sssd-devel about this. Another option would be to allow responders to run for less than 60 seconds (the minimum default time) ... let's say change it to 10 and then those tests would be way faster.
Would those changes be welcome? (I'll wait for your answer before dropping an email to sssd-devel). """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-372477710
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ So, I've figured out that there's no way for us to tell the difference about when sssd-kcm and sssd-secrets where started due to a socket activity or by `systemctl start sssd-{kcm,secrets}`.
I'm adding "Changes Requested" to this patch as we do *not* want to have the service shutting itself down in case it was explicitly started via systemd.
I'll do some more research on this and come up with a solution either in another PR or in this one ... but this PR should **not** be pushed till it's solved. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-373281272
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ Issue: https://pagure.io/SSSD/sssd/issue/3675 """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-373282953
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ We have discussed in a phone meeting Today that we will go for this patches and decide about https://pagure.io/SSSD/sssd/issue/3675 later.
Also, this PR will be split into code and tests parts in order to have the patches merged soon and we can keep discussing about the timeout used in the test side later on. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377256609
URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ I'm removing the "Changes Requested" label. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377258726
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
simo5 commented: """ Sorry for late comment, but should't you simply have a list of "inflight" calls and take that in consideration before deciding to shut down ? """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377265151
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """
Sorry for late comment, but should't you simply have a list of "inflight" calls and take that in consideration before deciding to shut down ?
Maybe. Do we already keep track of the "inflight" calls?
That's something that should be implemented and used for all responders, @simo5. So, in case we decide to go for it, I'd prefer to deal with this in a different PR (although I'm more than fine and want to have this discussion here before opening a ticket for that). Does that make sense? """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377267009
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
simo5 commented: """ Ok moving to a different PR, definitely. As for keeping a list, the best thing would be to not have explicit book keeping (as that's what you are fixing here), because when you write new code you invariable tend to forget about the book keeping and bugs creep in. I was thinking you may be able to simply look at the event context and figure out if there are pending operations there. If that is not easy then having some central place that does the book keeping indeed. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377273247
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
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ @jhrozek, @simo5,
Can we have this PR merged? I'll open a new ticket and paste the discussion I had with @simo5 here and I hope we can keep discussing it there. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384168824
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ Sorry, maybe I was waiting on you as well because I thought we didn't like the slow tests? I'll check the PR soon.. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384192460
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ That's true and you proposed to split this PR in two: this one just with the code and https://github.com/SSSD/sssd/pull/547 just with the tests, so we could decide what to do with the tests after having this one merged. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384233989
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
jhrozek commented: """ A quick idea about the tests - pytest support markers so we can add a marker like `@pytest.mark.slow`. Then, when running tests on the command line, we could say to only run tests that are not slow with `pytest -m "not slow"`. We might even add a literal `slow` to the test name and add a note to some contribute page that if you are irritated about slow tests, then here's how you run only the fast subset. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384775618
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ I like the idea. I will do the change and re-submit PR #547. """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384801241
URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ I've updated the patch set following @jhrozek's suggestion. Here is the output of a run with and without passing the "-m 'not slow'" to the tests: ``` [ffidenci@pessoa x86_64]$ make intgcheck-run INTGCHECK_PYTEST_ARGS="-k test_secrets.py" set -e; \ if [ ! -d intg/pfx ]; then make intgcheck-prepare; fi; \ cd intg/bld; \ make -C src/tests/intg intgcheck-installed; \ cd ../.. make[1]: Entering directory '/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg' pipepath="/tmp/sssd-intg.hls5nvgr/var/lib/sss/pipes"; \ if test ${#pipepath} -gt 80; then \ echo "error: Pipe directory path too long," \ "D-Bus won't be able to open sockets" >&2; \ exit 1; \ fi set -e; \ cd "/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg"; \ nss_wrapper=$(pkg-config --libs nss_wrapper); \ uid_wrapper=$(pkg-config --libs uid_wrapper); \ unset HOME; \ PATH="$(dirname -- /usr/sbin/slapd):$PATH" \ PATH="/tmp/sssd-intg.hls5nvgr/sbin:/tmp/sssd-intg.hls5nvgr/bin:$PATH" \ PATH="$PATH:/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg:/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg" \ PYTHONPATH="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg:/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg" \ LDB_MODULES_PATH="/tmp/sssd-intg.hls5nvgr/lib/ldb" \ NON_WRAPPED_UID=$(id -u) \ LD_PRELOAD="/tmp/sssd-intg.hls5nvgr/lib/getsockopt_wrapper.so:$nss_wrapper:$uid_wrapper" \ NSS_WRAPPER_PASSWD="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg/passwd" \ NSS_WRAPPER_GROUP="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg/group" \ NSS_WRAPPER_MODULE_SO_PATH="/tmp/sssd-intg.hls5nvgr/lib/libnss_sss.so.2" \ NSS_WRAPPER_MODULE_FN_PREFIX="sss" \ UID_WRAPPER=1 \ UID_WRAPPER_ROOT=1 \ DBUS_SOCK_DIR="/tmp/sssd-intg.hls5nvgr/var/run/dbus/" \ DBUS_SESSION_BUS_ADDRESS="unix:path=$DBUS_SOCK_DIR/fake_socket" \ DBUS_SYSTEM_BUS_ADDRESS="unix:path=$DBUS_SOCK_DIR/system_bus_socket" \ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS="$DBUS_SYSTEM_BUS_ADDRESS" \ fakeroot /usr/bin/python2 /usr/bin/py.test -v --tb=native -k test_secrets.py . ========================================================= test session starts ========================================================== platform linux2 -- Python 2.7.14, pytest-3.2.3, py-1.4.34, pluggy-0.4.0 -- /usr/bin/python2 cachedir: .cache rootdir: /home/brq/ffidenci/src/upstream/sssd/src/tests/intg, inifile: collected 261 items
test_secrets.py::test_crd_ops PASSED test_secrets.py::test_curlwrap_crd_ops PASSED test_secrets.py::test_curlwrap_parallel PASSED test_secrets.py::test_containers PASSED test_secrets.py::test_cli_idle_timeout PASSED test_secrets.py::test_global_quota PASSED test_secrets.py::test_sec_quota PASSED test_secrets.py::test_per_uid_limit PASSED test_secrets.py::test_unlimited_quotas PASSED test_secrets.py::test_resp_idle_timeout_shutdown_slow PASSED test_secrets.py::test_resp_idle_timeout_postpone_shutdown_slow PASSED
========================================================= 250 tests deselected ========================================================= ============================================= 11 passed, 250 deselected in 267.31 seconds ============================================== rm -f /tmp/sssd-intg.hls5nvgr/var/log/sssd/* make[1]: Leaving directory '/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg'
[ffidenci@pessoa x86_64]$ make intgcheck-run INTGCHECK_PYTEST_ARGS="-k test_secrets.py -m 'not slow'" set -e; \ if [ ! -d intg/pfx ]; then make intgcheck-prepare; fi; \ cd intg/bld; \ make -C src/tests/intg intgcheck-installed; \ cd ../.. make[1]: Entering directory '/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg' pipepath="/tmp/sssd-intg.hls5nvgr/var/lib/sss/pipes"; \ if test ${#pipepath} -gt 80; then \ echo "error: Pipe directory path too long," \ "D-Bus won't be able to open sockets" >&2; \ exit 1; \ fi set -e; \ cd "/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg"; \ nss_wrapper=$(pkg-config --libs nss_wrapper); \ uid_wrapper=$(pkg-config --libs uid_wrapper); \ unset HOME; \ PATH="$(dirname -- /usr/sbin/slapd):$PATH" \ PATH="/tmp/sssd-intg.hls5nvgr/sbin:/tmp/sssd-intg.hls5nvgr/bin:$PATH" \ PATH="$PATH:/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg:/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg" \ PYTHONPATH="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg:/home/brq/ffidenci/src/upstream/sssd/x86_64/../src/tests/intg" \ LDB_MODULES_PATH="/tmp/sssd-intg.hls5nvgr/lib/ldb" \ NON_WRAPPED_UID=$(id -u) \ LD_PRELOAD="/tmp/sssd-intg.hls5nvgr/lib/getsockopt_wrapper.so:$nss_wrapper:$uid_wrapper" \ NSS_WRAPPER_PASSWD="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg/passwd" \ NSS_WRAPPER_GROUP="/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg/group" \ NSS_WRAPPER_MODULE_SO_PATH="/tmp/sssd-intg.hls5nvgr/lib/libnss_sss.so.2" \ NSS_WRAPPER_MODULE_FN_PREFIX="sss" \ UID_WRAPPER=1 \ UID_WRAPPER_ROOT=1 \ DBUS_SOCK_DIR="/tmp/sssd-intg.hls5nvgr/var/run/dbus/" \ DBUS_SESSION_BUS_ADDRESS="unix:path=$DBUS_SOCK_DIR/fake_socket" \ DBUS_SYSTEM_BUS_ADDRESS="unix:path=$DBUS_SOCK_DIR/system_bus_socket" \ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS="$DBUS_SYSTEM_BUS_ADDRESS" \ fakeroot /usr/bin/python2 /usr/bin/py.test -v --tb=native -k test_secrets.py -m 'not slow' . ========================================================= test session starts ========================================================== platform linux2 -- Python 2.7.14, pytest-3.2.3, py-1.4.34, pluggy-0.4.0 -- /usr/bin/python2 cachedir: .cache rootdir: /home/brq/ffidenci/src/upstream/sssd/src/tests/intg, inifile: collected 261 items
test_secrets.py::test_crd_ops PASSED test_secrets.py::test_curlwrap_crd_ops PASSED test_secrets.py::test_curlwrap_parallel PASSED test_secrets.py::test_containers PASSED test_secrets.py::test_cli_idle_timeout PASSED test_secrets.py::test_global_quota PASSED test_secrets.py::test_sec_quota PASSED test_secrets.py::test_per_uid_limit PASSED test_secrets.py::test_unlimited_quotas PASSED
========================================================= 252 tests deselected ========================================================= ============================================== 9 passed, 252 deselected in 24.96 seconds =============================================== rm -f /tmp/sssd-intg.hls5nvgr/var/log/sssd/* make[1]: Leaving directory '/home/brq/ffidenci/src/upstream/sssd/x86_64/intg/bld/src/tests/intg' ``` """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384891382
URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ CI: http://vm-031.$%7Babc%7D/logs/job/88/20/summary.html """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384928060
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: +Pushed
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Label: -Accepted
URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ master: 8655dd0 cefadc6 26592d1 2f70065 04c236c 01ef93a 1ab24b3 ac9c3ad """
See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-384948849
URL: https://github.com/SSSD/sssd/pull/511 Author: fidencio Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ... Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/511/head:pr511 git checkout pr511
sssd-devel@lists.fedorahosted.org