On 02/07/2017 01:03 PM, Fabiano Fidêncio wrote:
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.
sd_notify talks through $NOTIFY_SOCKET env variable. Can you ask systemd
guys if this can be somehow set/created manually by the service? If it
can be done, this would be definitely the easiest way to do it.
Or maybe sd_pid_notify will work if there will be a pid file present?
Also how would systemd react if sssd responder shutdown if a process
already exists? The idea is that during the registration phase will
monitor send error that responder is already started and the new process
would exit.
Thus I've taken the approach to prefer systemd to monitor
whenever
it's possible.