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
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/GJ3AL7BSKLUMNYVTBTOWFQ2N7GDIFTS5/
