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.
LS