On Tue, Feb 7, 2017 at 12:58 PM, Pavel Březina <pbrezina(a)redhat.com> wrote:
On 02/07/2017 12:31 PM, Fabiano Fidêncio wrote:
>
> On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina <pbrezina(a)redhat.com>
> wrote:
>>
>> On 02/05/2017 11:24 PM, 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.
>>
>>
>>
>> Hi, I'm not sure I understand it correctly so let us clarify it.
>>
>>> 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;
>>
>>
>>
>> This means services = nss in sssd.conf, right?
>
>
> Yes, services = nss
>
>>
>>> - nss responder's socket is enabled;
>>
>>
>>
>> systemctl enable sssd-nss.socket?
>
>
> Yes, systemctl enable sssd-nss.socket
>
>>
>>> - boot the system
>>> - both nss processes will be up
>>
>>
>>
>> Why?
>
>
> As far as I have debugged what happens is:
> - monitor will start NSS responder because it's part of services line;
> - sssd-nss.socket will be up as, considering how the git master code
> is, it's part of sockets.target;
> - if any request goes to the nss socket, it will bring
> sssd-nss.service up and as the first was started by the monitor,
> systemd has no idea about a nss responder already running;
>
>>
>>> - Scenario 2
>>> - any responder is explicitly activated
>>> - systemctl enable sssd-@responder@.service
>>
>>
>>
>> In scenario 1 we are talking about socket, here about service. Is this
>> correct or a typo?
>
>
> That's a typo, but in the enable part. Consider the admin has pam
> responder in the services line ...
> - ssssd starts -> pam responder is running
> - admin does: systemctl start sssd-pam.service
>
> You will end up with two pam responders running at the same time.
>
>>
>> Why we end up running it twice?
>
>
> I hope I answered that above ...
>
>>
>>> 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 (Lukáš made his opinion quite clear that we should not be
>>> adding more logic to the monitor and I agree with him ... but maybe
>>> this case is an exception?) and also decide which of the approaches
>>> would be the less hackish one.
>>> Personally I'd go for always leaving the responder's startup to
>>> systemd, if possible. The main problem with this approach is that
>>> checking whether a the unit is loaded or not is done through sd-bus
>>> APIs, which may be to new for some enterprise distros (including
>>> CentOS here ...) /o\
>>>
>>> - Scenario 2:
>>> Here I do believe we could force the services to not be started
>>> manually as systemd already provides "RefuseManualStart=" option.
>>>
>>>
>>> I'm really looking forward to hearing your opinion on what would be
>>> the best approach to take, new ideas and so on.
>>>
>>>
>>> Best Regards,
>>> --
>>> Fabiano Fidêncio
>>
>>
>
> So, the path I've taken is:
> - If possible, always leave the service to be started up by systemd.
> IOW, we check whether the sssd-@responder@.socket is enabled. In case
> it is, just do not start the service through the monitor and let it be
> socket-activated when neede.
> - Refuse manual startup of the responders (and let they be
> automatically started up through socket-activation).
>
> Does that make sense?
Yes, thank you for explanation. Is it possible to use sd_notify() in
responders to tell systemd that the service is running?
I've checked that and as far I as understand it wouldn't work as the
service has not been started by systemd.
Thus I've taken the approach to prefer systemd to monitor whenever
it's possible.
>
>
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org