Hi Marcin, On 5/3/19 4:56 PM, Marcin Deranek wrote: > Hi Emeric, > > On 5/3/19 4:50 PM, Emeric Brun wrote: > >> I've a testing platform here but I don't use the usdm_drv but the >> qat_contig_mem and I don't reproduce this issue (I'm using QAT 1.5, as the >> doc says to use with my chip) . > > I see. I use qat 1.7 and qat-engine 0.5.40. > >> Anyway, could you re-compile a haproxy's binary if I provide you a testing >> patch? > > Sure, that should not be a problem.
The patch in attachment. > >> The idea is to perform a deinit in the master to force a close of those >> '/dev's at each reload. Perhaps It won't fix our issue but this leak of fd >> should not be. > > Hope this will give us at least some more insight.. > Regards, > > Marcin Deranek R, Emeric
>From ca57857a492e898759ef211a8fd9714d0f7dd7fa Mon Sep 17 00:00:00 2001 From: Emeric Brun <[email protected]> Date: Fri, 3 May 2019 17:06:59 +0200 Subject: [PATCH] BUG/MEDIUM: ssl: fix ssl engine's open fds are leaking. The master didn't call the engine deinit, resulting in a leak of fd opened by the engine during init. The workers inherit of these accumulated fds at each reload. This patch add a call to engine deinit on the master just before reloading with an exec. --- src/haproxy.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/haproxy.c b/src/haproxy.c index 603f084c..f77eb1b4 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@ -588,6 +588,13 @@ void mworker_reload() if (fdtab) deinit_pollers(); +#if defined(USE_OPENSSL) +#ifndef OPENSSL_NO_ENGINE + /* Engines may have opened fds and we must close them */ + ssl_free_engines(); +#endif +#endif + /* restore the initial FD limits */ limit.rlim_cur = rlim_fd_cur_at_boot; limit.rlim_max = rlim_fd_max_at_boot; -- 2.17.1
