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?
- nss responder's socket is enabled;
systemctl enable sssd-nss.socket?
- boot the system
- both nss processes will be up
Why?
- 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?
Why we end up running it twice?
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