On (08/02/17 12:37), Fabiano FidĂȘncio wrote:
On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik
<lslebodn(a)redhat.com> wrote:
> On (08/02/17 12:24), Fabiano FidĂȘncio wrote:
>>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.
>>
> Yes, I do not want to deal with misconfiguration.
> We might passively detect it and refuse such state.
> e.g. Fail if unix sockets are already created(by systemd) and monitor
> wants to start responders.
>
>>>
>>>>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.
>>
> I am not against to be robust. I am against magical workarounding
> such misconfuguration.
I do not understand why do you think using systemd when we can using
systemd is a magical workaroud.
Pulling info from systemd and checking state of services/sockets
is a magical workaround.
LS