On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote:
> Sure but what I wanted to say was that travis seems to be the only
> point experiencing such difficulties and we don't know how it works
> nor what are the rules in place.
I don't know whether this is related to the issue described here
Am 13.06.20 um 16:46 schrieb Tim Düsterhus:
> tune.ssl.default-dh-param 2048 solved the issue for me.
> I'd argue that this is a bug in HAProxy nonetheless, because apparently
> the crt-list file is not fully parsed in case of DH parameter warnings
> (not errors). In fact I can
I finally got around to upgrading my personal box from Debian Stretch to
Debian Buster. Unfortunately after the upgrade all my HTTP hosts failed
to work, because I use `strict-sni` as well as a strict `crt-list`.
Software versions before the upgrade:
Am 13.06.20 um 16:11 schrieb Tim Düsterhus:
> Any ideas?
Looking at the startup warnings is always a good idea:
> Jun 13 14:40:52 *snip* haproxy: [WARNING] 164/144052 (15815) :
> Reexecuting Master process
> Jun 13 14:40:52 *snip* haproxy: [WARNING] 164/144052
On Sat, Jun 13, 2020 at 03:13:06PM +0200, William Dauchy wrote:
> On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote:
> > Sure but what I wanted to say was that travis seems to be the only
> > point experiencing such difficulties and we don't know how it works
> > nor what
On Sun, Jun 14, 2020 at 01:20:43AM +0500, ??? wrote:
> I added "-O1" to travis builds.
> Can we apply it until a better solution will be found ?
Applied, thank you Ilya.
I added "-O1" to travis builds.
Can we apply it until a better solution will be found ?
пт, 12 июн. 2020 г. в 21:40, Илья Шипицин :
> пт, 12 июн. 2020 г. в 21:09, Willy Tarreau :
>> On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote:
>> > ??, 12 ???. 2020 ?. ? 20:46, Willy
On Sun, Jun 14, 2020 at 12:37:43AM +0200, Tim Duesterhus wrote:
> careful with this one: I don't know whether it's safe to simply free the
> expression there or whether I need to somehow check whether there actually
> is some expression.
> It does not crash with my stupid
Particularly cleanly deinit() after a configuration check to clean up the
output of valgrind which reports "possible losses" without a deinit() and
does not with a deinit(), converting actual losses into proper hard losses
which makes the whole stuff easier to analyze.
As an example, given an
careful with this one: I don't know whether it's safe to simply free the
expression there or whether I need to somehow check whether there actually
is some expression.
It does not crash with my stupid example configuration showcasing the leak,
but of course real world configurations might
This helper function calls deinit() and then exit() with the given status.
include/haproxy/global.h | 1 +
src/haproxy.c| 5 +
2 files changed, 6 insertions(+)
diff --git a/include/haproxy/global.h b/include/haproxy/global.h
index 4cf537403..1028c1b2a 100644
Mail list logo