On Wed, Feb 8, 2017 at 12:10 PM, Lukas Slebodnik <lslebodn(a)redhat.com> wrote:
On (05/02/17 23:24), Fabiano FidĂȘncio wrote:
>I've spent some amount of time trying to properly deal with this issue
>and I really need the opinion/suggestion of more experienced
>developers.
>
>Basically, as explained in #3300 this situation can happen is two
>scenarios were the admin is mixing up socket-activated and explicitly
>configured services:
>- Scenario 1:
> - nss responder is explicitly activated;
> - nss responder's socket is enabled;
> - boot the system
> - both nss processes will be up
>
This is pure misconfuguration and I do not think a reason why we shoudl solve
it.
Do you prefer to not deal with a misconfiguration scneraio (that may
not be caused by the admins themselves, but by the packager ...) even
if we can do that?
Interesting, at least.
>So, what I've thought so far, for each of the scenarios, is:
>- Scenario 1:
> Implement a way to either bypass the monitor in case the responder's
>socket it up or do not start the process through systemd in case one
>instance of the process is already being ran by the monitor. The main
>question here is how to do this without adding more logic to the
>monitor
What is a goal here?
The goal here is be bulletproof against wrong configurations/admins
trying to do something they're not supposed to.
But, as far as I understand from your previous comment, it's not of
your (and thus the project) interest to be robust on these cases.
Why do we want to bypass monitor?
I want to leave the responsibility to start a service to systemd
whenever it's possible.
Why? To avoid having two services of the same responder running.
Those patches are not strict needed unless we care at least a little
about robustness of SSSD.
Best Regards,