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
- Scenario 2
- any responder is explicitly activated
- systemctl enable sssd-@responder@.service
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