regtest: abns should work now :-)

Hi Ilya, I think this time I managed to fix the ABNS test. To make a long story short, it was by design extremely sensitive to the new process's startup time, which is increased with larger FD counts and/or less powerful VMs and/or noisy neighbors. This explains why it started to misbehave with th

Re: regtest: abns should work now :-)

well, I tried to repro abns failures on x86_64 I chose MS Azure VM of completely different size, both number of CPU and RAM. it was never reproduced, say on 1000 execution in loop. so, I decided "it looks like something with memory aligning". also, I tried to run arm64 emulation on virtualbox. no

Re: regtest: abns should work now :-)

osx were not stable few days on travis. s390x also. I think to wait for few days and if it will not be repaired, we will mark all those as "allowed failures" for good. пн, 23 мар. 2020 г. в 13:43, Willy Tarreau : > Hi Ilya, > > I think this time I managed to fix the ABNS test. To make a long sto

Re: regtest: abns should work now :-)

Hi Илья, On Mon, Mar 23, 2020 at 10:52 AM Илья Шипицин wrote: > well, I tried to repro abns failures on x86_64 > I chose MS Azure VM of completely different size, both number of CPU and > RAM. > it was never reproduced, say on 1000 execution in loop. > > so, I decided "it looks like something wi

Re: regtest: abns should work now :-)

On Mon, Mar 23, 2020 at 01:51:23PM +0500, ??? wrote: > osx were not stable few days on travis. > s390x also. > > I think to wait for few days and if it will not be repaired, we will mark > all those as "allowed failures" for good. Sounds good to me. Thanks! Willy

[ANNOUNCE] haproxy-2.2-dev5

Hi, HAProxy 2.2-dev5 was released on 2020/03/23. It added 99 new commits after version 2.2-dev4. During these last two weeks a lot of time was spent cleaning up code, doc and reg-tests. Fortunately in addition there are still some more visible features: - a unique ID may now be sent and receiv

Re: [PATCH] fix errored ARM64 builds in travis-ci

Hi Илья, On Sun, Mar 22, 2020 at 2:46 PM Илья Шипицин wrote: > Martin, > > as the one of the most interested in ARM64 builds, I've got news for you > > > can you try > > travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat > build-ssl.log && exit 1) > > in travis ? (please n

Re: [PATCH] fix memory leak, issue 559

Hi, This issue was introduced by #516. find_chain must not be freed. patch attached. > Le 21 mars 2020 à 15:23, Илья Шипицин a écrit : > > Hello, > > I attached patch that fixes memory leak, described in #559 > ++ Manu 0001-BUG-MINOR-ssl-memory-leak-when-find_chain-is-NULL.patch Descript

Re: Peers Protocol "Table Type"

Salut Willy, > >> The documented values are not used on any still supported haproxy's version. >> So I think it would be better to update the doc with the new ones >> and add a mapping to avoid further changes. > > Yep definitely. J'essaye de finir les scripts pour la gestion du SSD, et je suis

Re: [PATCH] fix memory leak, issue 559

On Mon, Mar 23, 2020 at 10:54:47AM +0100, Emmanuel Hocdet wrote: > > Hi, > > This issue was introduced by #516. > find_chain must not be freed. > patch attached. > > > Le 21 mars 2020 à 15:23, Илья Шипицин a écrit : > > > > Hello, > > > > I attached patch that fixes memory leak, described in

[RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close

Hello Mr. Willy Tarreau , I have created a patch to resolve following issue "https://github.com/haproxy/haproxy/issues/16"; . And I have generated the patch files by following the steps defined in "https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING"; document. Request you to please revi

[PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain

As discussed in #559 0001-CLEANUP-ssl-rename-ssl_get_issuer_chain-to-ssl_get0_.patch Description: Binary data

Re: [PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain

On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote: > > As discussed in #559 > Can't we return directly a STACK_OF(X509)* structure instead of the struct issuer_chain * ? Because I have the impression that we use the struct issuer_chain only to lookup and we only use the chain fiel

Re: [PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain

> Le 23 mars 2020 à 15:12, William Lallemand a écrit : > > On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote: >> >> As discussed in #559 >> > > Can't we return directly a STACK_OF(X509)* structure instead of the > struct issuer_chain * ? > > Because I have the impression that w

Re: [PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain

On Mon, Mar 23, 2020 at 03:26:20PM +0100, Emmanuel Hocdet wrote: > > > Le 23 mars 2020 à 15:12, William Lallemand a écrit : > > > > On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote: > >> > >> As discussed in #559 > >> > > > > Can't we return directly a STACK_OF(X509)* structure

[PATCH] MINOR: ssl: rework add cert chain to CTX to be libssl independent

Hi,This patch remove #ifdef compatibility for add cert chain to CTX, goal is to simplify code.It’s an extract from "[PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx » proposal.++Manu 0001-MINOR-ssl-rework-add-cert-chain-to-CTX-to-be-libssl-.patch Description: Binary data

[PATCH] 5th iteration of typo fixes

Hello, I can send typo fixes weekly. Cheers, Ilya Shipitcin From 6f06c0fdd87ac14e8e553ac823646d2504944f25 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Mon, 23 Mar 2020 22:28:40 +0500 Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments This is fifth iteration of typo fi

Re: Segfault on 2.1.3

I'm pretty sure that we are seeing "the service is down", though only briefly. We started looking at the logs because we were seeing testing failures and failures with our code deploys, which check the haproxy status as part of rolling the code update to the machines. We aren't manually having to