Hi list,
The attached patch covers ticket #3080 (https://fedorahosted.org/sssd/ticket/3080). It's based on the following commit: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=d19c4785215305e6eb5f2f...
Currently, systemd and upstart set the service as 'started' before the responders are available, making service dependencies (with autofs, for instance) unreliable due to a race condition with such dependent services. Creating the pidfile after the responders are up, and monitoring it's creation in the systemd service fixes this race condition.
Thanks in advance,
Victor
On (12/08/16 11:48), Victor Tapia wrote:
Hi list,
The attached patch covers ticket #3080 (https://fedorahosted.org/sssd/ticket/3080). It's based on the following commit: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=d19c4785215305e6eb5f2f...
Currently, systemd and upstart set the service as 'started' before the responders are available, making service dependencies (with autofs, for instance) unreliable due to a race condition with such dependent services. Creating the pidfile after the responders are up, and monitoring it's creation in the systemd service fixes this race condition.
Thank you very much for the patch. I tried to look into systemd documentation and I could not see anything in documentation which would say that it is a reliable way to use a pid file. (It might change in future if it is not documented)
man systemd.service says If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits. //snip PIDFile= Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists.
It might help for upstart but for systemd it might be better to use "Type=notify" instead of "Type=forking".
Is the bug reproducible only with upstart or also with systemd? For systemd only I would prefer "Type=notify"
LS
Hi Lukas,
I tried to look into systemd documentation and I could not see anything in documentation which would say that it is a reliable way to use a pid file. (It might change in future if it is not documented)
man systemd.service says If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits. //snip PIDFile= Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists.
It might help for upstart but for systemd it might be better to use "Type=notify" instead of "Type=forking".
I haven't tried using "Type=notify", but I don't think it would make a difference if we can't hold the notification signal until the responders are running.
Is the bug reproducible only with upstart or also with systemd? For systemd only I would prefer "Type=notify"
I've been able to reproduce this bug in both upstart and systemd, but the numbers differ significantly (~40% of the runs with upstart, ~1% or less with systemd).
Kind regards,
Victor
On (12/08/16 14:34), Victor Tapia wrote:
Hi Lukas,
I tried to look into systemd documentation and I could not see anything in documentation which would say that it is a reliable way to use a pid file. (It might change in future if it is not documented)
man systemd.service says If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits. //snip PIDFile= Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists.
It might help for upstart but for systemd it might be better to use "Type=notify" instead of "Type=forking".
I haven't tried using "Type=notify", but I don't think it would make a difference if we can't hold the notification signal until the responders are running.
You would need to call sd_*notify function after initialisation of responders man 3 sd_notify https://www.freedesktop.org/software/systemd/man/sd_notify.html It would solve a problem in a different way.
Is the bug reproducible only with upstart or also with systemd? For systemd only I would prefer "Type=notify"
I've been able to reproduce this bug in both upstart and systemd, but the numbers differ significantly (~40% of the runs with upstart, ~1% or less with systemd).
In that case, I think we can merge the patch. But I would like to do some regression testing with upstart(CentOS6).
LS
I haven't tried using "Type=notify", but I don't think it would make a difference if we can't hold the notification signal until the responders are running.
You would need to call sd_*notify function after initialisation of responders man 3 sd_notify https://www.freedesktop.org/software/systemd/man/sd_notify.html It would solve a problem in a different way.
My fault, I misunderstood the systemd doc regarding who did the call.
Is the bug reproducible only with upstart or also with systemd? For systemd only I would prefer "Type=notify"
I've been able to reproduce this bug in both upstart and systemd, but the numbers differ significantly (~40% of the runs with upstart, ~1% or less with systemd).
In that case, I think we can merge the patch. But I would like to do some regression testing with upstart(CentOS6).
Sounds good to me, thanks Lukas!
Regards,
Victor
On (12/08/16 16:08), Victor Tapia wrote:
I haven't tried using "Type=notify", but I don't think it would make a difference if we can't hold the notification signal until the responders are running.
You would need to call sd_*notify function after initialisation of responders man 3 sd_notify https://www.freedesktop.org/software/systemd/man/sd_notify.html It would solve a problem in a different way.
My fault, I misunderstood the systemd doc regarding who did the call.
Is the bug reproducible only with upstart or also with systemd? For systemd only I would prefer "Type=notify"
I've been able to reproduce this bug in both upstart and systemd, but the numbers differ significantly (~40% of the runs with upstart, ~1% or less with systemd).
In that case, I think we can merge the patch. But I would like to do some regression testing with upstart(CentOS6).
Sounds good to me, thanks Lukas!
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
LS
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
Thanks,
Victor
On (26/08/16 13:16), Victor Tapia wrote:
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
Thanks,
Victor
From 65f587535fae28719d3f2455fe144dd008361d52 Mon Sep 17 00:00:00 2001 From: Victor Tapia victor.tapia@canonical.com Date: Fri, 26 Aug 2016 13:01:32 +0200 Subject: [PATCH] Create pidfile after responders started
Makefile.am | 1 + src/monitor/monitor.c | 42 ++++++++++++++++++++++++++++++++++++---- src/sysv/sssd.in | 11 +++++++++++ src/sysv/systemd/sssd.service.in | 3 ++- 4 files changed, 52 insertions(+), 5 deletions(-)
Thank you very much for updated version.
It will take me some time to test the patch. But it's on my TODO list.
LS
On (26/08/16 13:16), Victor Tapia wrote:
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
I ran tests and I do not understand why but some tests on rhel6 were stucked in weird state. I'm not sure whether it's caused by your patch or by wrong expectation in tests. I will also try to test with 1.13.
But so far it seems to work with systemd.
LS
El 01/09/16 a las 14:50, Lukas Slebodnik escribió:
On (26/08/16 13:16), Victor Tapia wrote:
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
I ran tests and I do not understand why but some tests on rhel6 were stucked in weird state. I'm not sure whether it's caused by your patch or by wrong expectation in tests. I will also try to test with 1.13.
But so far it seems to work with systemd.
LS
Hi Lukas,
here's the last iteration of the patch for 1.14.2, including the upstart service script.
Thanks,
Victor
On (08/09/16 12:29), Victor Tapia wrote:
El 01/09/16 a las 14:50, Lukas Slebodnik escribió:
On (26/08/16 13:16), Victor Tapia wrote:
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
I ran tests and I do not understand why but some tests on rhel6 were stucked in weird state. I'm not sure whether it's caused by your patch or by wrong expectation in tests. I will also try to test with 1.13.
But so far it seems to work with systemd.
LS
Hi Lukas,
here's the last iteration of the patch for 1.14.2, including the upstart service script.
I noticed some changes also in monitor.c. Did you found some issues in your testing?
May I asked what is a difference between sysv initscript and upstart? I am fine with conditional including especially if you would use the same script in downstream(ubuntu) :-)
LS
El 08/09/16 a las 13:13, Lukas Slebodnik escribió:
On (08/09/16 12:29), Victor Tapia wrote:
El 01/09/16 a las 14:50, Lukas Slebodnik escribió:
On (26/08/16 13:16), Victor Tapia wrote:
Hi,
Sorry for the late response, I've been out for nearly two weeks. I'm attaching a new version of the patch to review.
Does upstart/init script need to be updated as well? We have some generic in src/sysv/sssd.in
Upstart does need to keep track of the pidfile creation. I can't see a service file, so I'll prepare one.
Regarding sysv, due to its sequential nature, it's dangerous to include an infinite loop because it could stuck the normal boot of the machine. I included a timeout in the loop to avoid this, please let me know what you think about it.
BTW the patch causes some failures for me on rhel6. According to logs, the file /var/run/sssd.pid did not exist in some cases.
Please also remove changes in src/sysv/systemd/sssd.service.in in next version. For systemd only I would prefer "Type=notify".
Done, I've switched to Type=notify for systemd.
I ran tests and I do not understand why but some tests on rhel6 were stucked in weird state. I'm not sure whether it's caused by your patch or by wrong expectation in tests. I will also try to test with 1.13.
But so far it seems to work with systemd.
LS
Hi Lukas,
here's the last iteration of the patch for 1.14.2, including the upstart service script.
I noticed some changes also in monitor.c. Did you found some issues in your testing?
May I asked what is a difference between sysv initscript and upstart? I am fine with conditional including especially if you would use the same script in downstream(ubuntu) :-)
LS
The changes in monitor.c should be only positional, because the previous patch was meant to be applied on 1.14.1. I used fedora 24 to prepare this patch and had no issues with the tests (luckily!).
Regarding the upstart script, I thought it was requested to be included in the patch, my fault. In ubuntu we require an apparmor profile load, so it wouldn't make any sense to include it upstream, but thanks anyway :)
Should we stick to the previous patch, then?
Thanks,
Victor
Hi,
I just saw that the ticket 3080 (https://fedorahosted.org/sssd/ticket/3080) has been closed with a different patch. Is this one landing too?
Thanks,
Victor
On Thu, Sep 22, 2016 at 10:07:21AM -0000, Victor Tapia wrote:
Hi,
I just saw that the ticket 3080 (https://fedorahosted.org/sssd/ticket/3080) has been closed with a different patch. Is this one landing too?
Sorry, that's my fault, I put a wrong URL into patches for #3140. I reopened #3080.
Hi,
I just removed the upstart part and left just the systemd notification with the fix for the latest master branch. I also fixed the evaluation of the return code of sd_notify from the original patch, so this should be the "good" one :).
Thanks,
Victor
El 22/09/16 a las 12:31, Jakub Hrozek escribió:
On Thu, Sep 22, 2016 at 10:07:21AM -0000, Victor Tapia wrote:
Hi,
I just saw that the ticket 3080 (https://fedorahosted.org/sssd/ticket/3080) has been closed with a different patch. Is this one landing too?
Sorry, that's my fault, I put a wrong URL into patches for #3140. I reopened #3080. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
On Mon, Oct 03, 2016 at 05:44:19PM +0200, Victor Tapia wrote:
Hi,
I just removed the upstart part and left just the systemd notification with the fix for the latest master branch. I also fixed the evaluation of the return code of sd_notify from the original patch, so this should be the "good" one :).
Thank you for the patch, since Lukas did some work testing it, I would prefer to leave the code review for him, I'll just note that Lukas is on vacation for about two more weeks, so there may be a delay in the review..
Please let us know if this patch is holding back some Ubuntu release, then I guess someone else could take a stab at reviewing it..
El 03/10/16 a las 21:34, Jakub Hrozek escribió:
On Mon, Oct 03, 2016 at 05:44:19PM +0200, Victor Tapia wrote:
Hi,
I just removed the upstart part and left just the systemd notification with the fix for the latest master branch. I also fixed the evaluation of the return code of sd_notify from the original patch, so this should be the "good" one :).
Thank you for the patch, since Lukas did some work testing it, I would prefer to leave the code review for him, I'll just note that Lukas is on vacation for about two more weeks, so there may be a delay in the review..
Please let us know if this patch is holding back some Ubuntu release, then I guess someone else could take a stab at reviewing it.. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
This patch can wait for Lukas, no worries :).
Thanks,
Victor
Hi Lukas,
could you review this patch and let me if it's ok as it is?
Thanks,
Victor
Hi Lukas,
please let me know if you need anything else for this patch.
Regards,
Victor
On (03/10/16 17:44), Victor Tapia wrote:
Hi,
I just removed the upstart part and left just the systemd notification with the fix for the latest master branch. I also fixed the evaluation of the return code of sd_notify from the original patch, so this should be the "good" one :).
Thanks,
Victor
El 22/09/16 a las 12:31, Jakub Hrozek escribió:
On Thu, Sep 22, 2016 at 10:07:21AM -0000, Victor Tapia wrote:
Hi,
I just saw that the ticket 3080 (https://fedorahosted.org/sssd/ticket/3080) has been closed with a different patch. Is this one landing too?
Sorry, that's my fault, I put a wrong URL into patches for #3140. I reopened #3080. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
From f0b08423e7d215aee49e23a713e53df2c61a239e Mon Sep 17 00:00:00 2001 From: Victor Tapia victor.tapia@canonical.com Date: Mon, 3 Oct 2016 17:36:08 +0200 Subject: [PATCH] Create pidfile after responders started
Makefile.am | 1 + src/monitor/monitor.c | 42 ++++++++++++++++++++++++++++++++++++---- src/sysv/sssd.in | 15 ++++++++++++++ src/sysv/systemd/sssd.service.in | 3 ++- 4 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/Makefile.am b/Makefile.am index 1ea8f50..fc25a24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1246,6 +1246,7 @@ sssd_LDADD = \ $(INOTIFY_LIBS) \ $(LIBNL_LIBS) \ $(KEYUTILS_LIBS) \
- $(SYSTEMD_DAEMON_LIBS) \ $(SSSD_INTERNAL_LTLIBS)
sssd_nss_SOURCES = \ diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c index 84a144e..49624e6 100644 --- a/src/monitor/monitor.c +++ b/src/monitor/monitor.c @@ -55,6 +55,10 @@ #include <keyutils.h> #endif
+#ifdef HAVE_SYSTEMD +#include <systemd/sd-daemon.h> +#endif
/* terminate the child after this interval by default if it
- doesn't shutdown on receiving SIGTERM */
#define MONITOR_DEF_FORCE_TIME 60 @@ -160,6 +164,7 @@ struct mt_ctx { struct netlink_ctx *nlctx; const char *conf_path; struct sss_sigchild_ctx *sigchld_ctx;
- bool pid_file_created; bool is_daemon; pid_t parent_pid;
@@ -439,7 +444,29 @@ static int mark_service_as_started(struct mt_svc *svc) ctx->started_services++; }
- if (ctx->started_services == ctx->num_services) {
- /* create the pid file if all services are alive */
- if (!ctx->pid_file_created && ctx->started_services == ctx->num_services) {
DEBUG(SSSDBG_TRACE_FUNC, "All services have successfully started, ""creating pid file\n");ret = pidfile(PID_PATH, MONITOR_NAME);if (ret != EOK) {DEBUG(SSSDBG_FATAL_FAILURE,"Error creating pidfile: %s/%s.pid! (%d [%s])\n",PID_PATH, MONITOR_NAME, ret, strerror(ret));kill(getpid(), SIGTERM);}ctx->pid_file_created = true;+#ifdef HAVE_SYSTEMD
DEBUG(SSSDBG_TRACE_FUNC, "Sending startup notification to systemd\n");ret = sd_notify(0, "READY=1");if (ret < 0) {DEBUG(SSSDBG_CRIT_FAILURE, "Error sending notification to systemd"" %d: %s\n", -ret, strerror(-ret));}+#endif
/* Initialization is complete, terminate parent process if in daemon * mode. Make sure we send the signal to the right process */ if (ctx->is_daemon) {@@ -1495,6 +1522,7 @@ errno_t load_configuration(TALLOC_CTX *mem_ctx, return ENOMEM; }
ctx->pid_file_created = false; talloc_set_destructor((TALLOC_CTX *)ctx, monitor_ctx_destructor);
cdb_file = talloc_asprintf(ctx, "%s/%s", DB_PATH, CONFDB_FILE);
@@ -2601,9 +2629,6 @@ int main(int argc, const char *argv[]) return 6; }
- /* we want a pid file check */
- flags |= FLAGS_PID_FILE;
- /* Open before server_setup() does to have logging
if (debug_to_file) {
- during configuration checking */
@@ -2668,6 +2693,15 @@ int main(int argc, const char *argv[]) } }
- /* Check if the SSSD is already running */
- ret = check_file(SSSD_PIDFILE, 0, 0, S_IFREG|0600, 0, NULL, false);
- if (ret == EOK) {
DEBUG(SSSDBG_FATAL_FAILURE,"pidfile exists at %s\n", SSSD_PIDFILE);ERROR("SSSD is already running\n");return 2;- }
- /* Parse config file, fail if cannot be done */ ret = load_configuration(tmp_ctx, config_file, CONFDB_DEFAULT_CONFIG_DIR, &monitor);
diff --git a/src/sysv/sssd.in b/src/sysv/sssd.in index 5109148..385785e 100644 --- a/src/sysv/sssd.in +++ b/src/sysv/sssd.in @@ -40,6 +40,8 @@ SSSD=@sbindir@/sssd LOCK_FILE=@localstatedir@/lock/subsys/sssd PID_FILE=@localstatedir@/run/sssd.pid
+TIMEOUT=15
start() { [ -x $SSSD ] || exit 5 echo -n $"Starting $prog: " @@ -47,6 +49,19 @@ start() { RETVAL=$? echo [ "$RETVAL" = 0 ] && touch $LOCK_FILE
- # Wait for pidfile creation or timeout
- sec=0
- [ "$RETVAL" = 0 ] && while [ $sec -lt $TIMEOUT -a ! -f $PID_FILE ]
- do
sleep 1sec=$(($sec+1))- done
- if [ "$sec" = "$TIMEOUT" ]; then
RETVAL=-1- fi
- return $RETVAL
}
diff --git a/src/sysv/systemd/sssd.service.in b/src/sysv/systemd/sssd.service.in index a4f9125..976c9c1 100644 --- a/src/sysv/systemd/sssd.service.in +++ b/src/sysv/systemd/sssd.service.in @@ -9,7 +9,8 @@ EnvironmentFile=-@environment_file@ ExecStart=@sbindir@/sssd -D -f # These two should be used with traditional UNIX forking daemons # consult systemd.service(5) for more details -Type=forking +Type=notify +NotifyAccess=all PIDFile=@localstatedir@/run/sssd.pid
PIDFile is usually not used with "Type=notify" because behavior of "notify" is similar to "simple" Therefore it is better to run sssd in interactive mode and not in daemon mode s/-D/-i/.
This would also allow us to change NotifyAccess from all -> main. Because that is what code does :-)
To simplify things I am attaching updated patch with my singoff. I hope you don't mind that I fixed few coding style issues as well. There might be some comflicts when applying the patch to 1.13 due to new flag FLAGS_NO_WATCHDOG in 1.14+
I had to reschedule jobs because I didn't properly solve conflict with removing FLAGS_PID_FILE I hope the latest patch will work without issues :-) I let you know after that.
LS
Hi, I was out last week, sorry for the delay!
The patch looks good to me, I'll try to test it too as soon as I find some time.
Thanks,
Victor
Hi Lukas,
Just wanted to confirm your patch works for me.
Kind regards,
Victor
On (20/12/16 15:02), Victor Tapia wrote:
Hi Lukas,
Just wanted to confirm your patch works for me.
Thank you very much for confirmation and contribution. It took me some times to process many mails after christmas holiday. And sorry for long delays in review process.
master: http://sssd-ci.duckdns.org/logs/job/59/85/summary.html * d4063e9a21a4e203bee7e0a0144fa8cabb14cc46
sssd-1-14: http://sssd-ci.duckdns.org/logs/job/59/86/summary.html * 12c36167aff5227d1b1f53988a748283dbb292d9
sssd-1-13: http://sssd-ci.duckdns.org/logs/job/59/87/summary.html * 0f7df9c3c7e2fa177da7ec59a261ac3d2e1fbcda * 1d897ffa2f6c675a98e27b4f8f336dcda6ea8c80
LS
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Victor Tapia