Hi,
This is more of a realmd question than sssd, but closely related.
Debian and Ubuntu defaulted to socket activated systemd services for all the sssd-* daemons. So they are started on demand.
realmd currently always adds a "services = nss, pam" line (or augments it if it's there already). sssd will then start nss and pam, but so will systemd, and that creates a (apparently harmless) conflict and logs errors to the logs.
I don't know if there is a way for realmd to detect this scenario and not add that services line, or if there should be a command-line option for it? Or maybe something in realm-<distro>.conf even?
At the moment I'm just disabling adding the services line. Is this too horrible?
--- a/service/realm-sssd-config.c +++ b/service/realm-sssd-config.c @@ -154,8 +154,6 @@ g_strfreev (already);
/* Setup a default sssd section */ - if (!realm_ini_config_have (config, "section", "services")) - realm_ini_config_set (config, "sssd", "services", "nss, pam", NULL); if (!realm_ini_config_have (config, "sssd", "config_file_version")) realm_ini_config_set (config, "sssd", "config_file_version", "2", NULL);
--- a/tests/test-sssd-config.c +++ b/tests/test-sssd-config.c @@ -90,7 +90,7 @@ gconstpointer unused) { const gchar *data = "[domain/one]\nval=1\n[sssd]\ndomains=one"; - const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one, two\nconfig_file_version = 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n"; + const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one, two\nconfig_file_version = 2\n\n[domain/two]\ndos = 2\n"; GError *error = NULL; gchar *output; gboolean ret; @@ -140,7 +140,7 @@ test_add_domain_only (Test *test, gconstpointer unused) { - const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version = 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n"; + const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version = 2\n\n[domain/two]\ndos = 2\n"; GError *error = NULL; gchar *output; gboolean ret;
On Tue, Sep 8, 2020, at 10:53 AM, Andreas Hasenack wrote:
Hi,
This is more of a realmd question than sssd, but closely related.
Debian and Ubuntu defaulted to socket activated systemd services for all the sssd-* daemons. So they are started on demand.
realmd currently always adds a "services = nss, pam" line (or augments it if it's there already). sssd will then start nss and pam, but so will systemd, and that creates a (apparently harmless) conflict and logs errors to the logs.
I don't know if there is a way for realmd to detect this scenario and not add that services line, or if there should be a command-line option for it? Or maybe something in realm-<distro>.conf even?
At the moment I'm just disabling adding the services line. Is this too horrible?
In my experience on RHEL 8, some of the services are unreliable when activated in this manner. The services line never fails. I believe the .service (or .socket) files on RHEL 8 are written to avoid any collision. Specially, I think the socket activated version is a no op if the services line one is running.
V/r, James Cassell
--- a/service/realm-sssd-config.c +++ b/service/realm-sssd-config.c @@ -154,8 +154,6 @@ g_strfreev (already);
/* Setup a default sssd section */
- if (!realm_ini_config_have (config, "section", "services"))
realm_ini_config_set (config, "sssd", "services", "nss, pam", NULL);--- a/tests/test-sssd-config.c +++ b/tests/test-sssd-config.c @@ -90,7 +90,7 @@ gconstpointer unused) { const gchar *data = "[domain/one]\nval=1\n[sssd]\ndomains=one";
- const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
two\nconfig_file_version = 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n";
- const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
two\nconfig_file_version = 2\n\n[domain/two]\ndos = 2\n"; GError *error = NULL; gchar *output; gboolean ret; @@ -140,7 +140,7 @@ test_add_domain_only (Test *test, gconstpointer unused) {
- const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
= 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n";
- const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
= 2\n\n[domain/two]\ndos = 2\n"; GError *error = NULL; gchar *output; gboolean ret;
Hello James,
thanks for the reply
On Tue, Sep 8, 2020 at 3:45 PM James Cassell fedoraproject@cyberpear.com wrote:
At the moment I'm just disabling adding the services line. Is this too horrible?
In my experience on RHEL 8, some of the services are unreliable when activated in this manner. The services line never fails. I believe the .service (or .socket) files on RHEL 8 are written to avoid any collision. Specially, I think the socket activated version is a no op if the services line one is running.
Do you have some pointers to such issues, like bug reports or mailing list posts?
Debian and Ubuntu use the upstream systemd service files as is, with no changes, and we do see conflicts when services= is used together with socket activation.
On Wed, Sep 9, 2020 at 9:58 AM Andreas Hasenack andreas@canonical.com wrote:
Debian and Ubuntu use the upstream systemd service files as is, with no changes, and we do see conflicts when services= is used together with socket activation.
Perhaps the best conclusion to draw from this is that activating sssd services via the "services" line should be preferred over socket-based activation?
The main purpose of socket-based activation is to make it easier to parallelize the launching of services at boot time:
http://0pointer.de/blog/projects/socket-activation.html
But socket-based activation introduces a nontrivial startup time penalty if the service is not already running when a call against it is made. And as you’ve discovered, it can create conflicts if sssd is also attempting to launch child services via the services= line.
I suspect in most cases, paying these penalties just in order to shave 0.25 seconds off the system boot time isn’t a good trade-off.
On 9/9/20 12:42 PM, James Ralston wrote:
The main purpose of socket-based activation is to make it easier to parallelize the launching of services at boot time:
Well, also used as a drop in replacement for inetd; for services which are used only occasionally, but that's even *less* applicable to sssd.
Anything which is in constant use should be started as a service rather than a socket, and the example given in the blog post -- sshd -- isn't even valid any more. sshd dropped support for socket activation because of some security issue.
sssd-users@lists.fedorahosted.org
-
Andreas Hasenack -
James Cassell -
James Ralston -
Patrick Goetz