URL:
https://github.com/SSSD/sssd/pull/132
Title: #132: Add "Wants=" to sssd unit
pbrezina commented:
"""
OK. It was not related. Patches works as expected so ACK to the patches but...
Services that are enabled through sssd.conf yields the following warning, which is
correct:
```
[root /var/lib/sss/db]# systemctl status sssd-nss.socket
● sssd-nss.socket - SSSD NSS Service responder socket
Loaded: loaded (/usr/lib/systemd/system/sssd-nss.socket; disabled; vendor preset:
disabled)
Active: failed (Result: exit-code) since Mon 2018-08-20 11:57:03 CEST; 6min ago
Docs: man:sssd.conf(5)
Listen: /var/lib/sss/pipes/nss (Stream)
Aug 20 11:57:03 pbrezina.my systemd[1]: Starting SSSD NSS Service responder socket.
Aug 20 11:57:03 pbrezina.my sssd[9458]: There's a misconfiguration in the
"services" line of "/etc/sssd/sssd.conf"!
The "services" line contains
"nss", meaning that the responder's process will be started and managed by
SSSD's monitor. However, SSSD relies on s
In order to solve this misconfiguration, please,
either remove "nss" from the "services" line in
"/etc/sssd/sssd.conf" or call `systemctl mask ss
Please, refer to "sssd.conf" man page
for more info and mind that the recommended way to go is to take advantage of systemd, as
much as possible,
Aug 20 11:57:03 pbrezina.my systemd[1]: sssd-nss.socket: Control process exited,
code=exited status=17
Aug 20 11:57:03 pbrezina.my systemd[1]: Failed to listen on SSSD NSS Service responder
socket.
Aug 20 11:57:03 pbrezina.my systemd[1]: sssd-nss.socket: Unit entered failed state.
```
However, I'm not sure if this is something desirable for all responders. Everyone have
`nss` and `pam` services enabled through `sssd.conf` from its beginning and socket
activation use case is not really desirable for them as you want to authenticate and id
fast very often.
I already mentioned it on the meeting and I will mention it again just so the idea gets
proper thoughts. If we are going to enable all responders/sockets and rely on systemd by
default maybe it is time to drop this functionality from monitor (also we are now in 2.0
so we can do such change).
* We can rely completely on systemd to manage socket and services start and monitor.
* If a service is present in sssd.conf, it will have no idle timeout and it will run
indefinitely.
* If a service is not present in sssd.conf, it will terminated itself after some time as
it is now.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/132#issuecomment-414268841