Re: Segfault on 2.1.3

[Sean Reifschneider]

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 restart the service via "service haproxy restart", for example,
just to clarify.

I'm not sure I'm answering your first question, if the above doesn't answer
it, how do I tell if it's the "old one" or the "new one"?  I think you mean
that an haproxy process is restarting at some point during the run and
which one.  Or do you mean the 2.0.13 process before update ("old one") and
the 2.1.3 process after update ("new one").  To clarify: We install the
2.1.3 package, and then with no further interaction that I know of, we get
a few handfuls of segfaults in the logs.

It happens incredibly infrequently.  1-10 times a day.  I wondered if it
might be related to a lot of hits from a single IP address, but manually
doing a bunch of reloads in my web browser, didn't trigger it.  We really
have no idea what triggers it and can't reproduce it at will.

I'm pretty sure we don't have anything that updates the ACL.  At some point
in the past we had a cron job that would query the ratelists to store off
stats, but nothing that updated them, and I don't see that we have that job
on the system after the upgrade (new system spin when we did the haproxy
update).

Thanks,
Sean

On Sat, Mar 21, 2020 at 3:33 AM Willy Tarreau  wrote:

> On Sat, Mar 21, 2020 at 10:08:15AM +0100, Willy Tarreau wrote:
> > On Fri, Mar 20, 2020 at 08:10:25AM -0600, Sean Reifschneider wrote:
> > > I grabbed the source from the PPA and rebuilt it, installed the dbg
> > > package, and here's one of the "bt full"s:
> >
> > Thanks!
> >
> > > (gdb) bt full
> > > #0  pattern_exec_match (head=head@entry=0x55e4dd275478,
> > > smp=smp@entry=0x7fbf9ef650c0,
> > > fill=fill@entry=0) at src/pattern.c:2541
> > > __pl_l = 
> > > __pl_r = 
> > > list = 0x0
> > > pat = 
> >
> > This is very strange. The "list" field is null for the expression. That
> > doesn't make much sense in a linked list. This makes me suspect that the
> > previous element was added then freed without being unlinked and was then
> > reused and zeroed.
> >
> > I wanted to issue dev5 right now but I'll first try to figure if this is
> > reproducible and if so, how.
>
> I obviously can't reproduce it and the only line in your config making
> use of L4 rules is perfectly fine and straightforward.
>
> Thus I'm having two questions:
>   - is it the new or the old process that occasionally crashes on reload ?
> If it's the new one, the service is down. If it's the old one, the
> service continues and you only know about it from your logs.
>
>   - do you have anything that tries to update the "rate_whitelist" ACL
> over the stats socket ? We could for example imagine that you're
> maintaining a whitelist in a separate file that you're uploading
> upon reloads.
>
> Thanks,
> Willy
>

[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 fixes
---
 contrib/deviceatlas/dac.h |  2 +-
 contrib/mod_defender/spoa.c   |  2 +-
 contrib/modsecurity/modsec_wrapper.c  |  4 ++--
 contrib/modsecurity/spoa.c|  2 +-
 contrib/plug_qdisc/plug_qdisc.c   |  2 +-
 .../prometheus-exporter/service-prometheus.c  | 20 +--
 contrib/spoa_example/include/spoe_types.h |  2 +-
 contrib/spoa_example/spoa.c   |  2 +-
 contrib/spoa_server/ps_lua.c  |  4 ++--
 contrib/spoa_server/ps_python.c   |  4 ++--
 contrib/spoa_server/spoa.c| 10 +-
 .../wireshark-dissectors/peers/packet-happp.c |  2 +-
 contrib/wurfl/wurfl/wurfl.h   |  2 +-
 src/connection.c  |  4 ++--
 src/ev_evports.c  |  2 +-
 src/hlua_fcn.c| 10 +-
 src/raw_sock.c|  2 +-
 17 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/contrib/deviceatlas/dac.h b/contrib/deviceatlas/dac.h
index 4e0189a71..92a9396c0 100644
--- a/contrib/deviceatlas/dac.h
+++ b/contrib/deviceatlas/dac.h
@@ -70,7 +70,7 @@ enum da_status {
 enum da_severity {
 DA_SEV_FATAL, /* The operation will not continue, and the operation will return an error. */
 DA_SEV_ERROR, /* An error occurred, but the API call will return at least some valid information */
-DA_SEV_WARN,  /* An unexpected event occured, but the system dealt with it */
+DA_SEV_WARN,  /* An unexpected event occurred, but the system dealt with it */
 DA_SEV_INFO   /* An informational message. */
 };
 /* Forward references to tagged types */
diff --git a/contrib/mod_defender/spoa.c b/contrib/mod_defender/spoa.c
index 94e6d6bda..079e880cb 100644
--- a/contrib/mod_defender/spoa.c
+++ b/contrib/mod_defender/spoa.c
@@ -192,7 +192,7 @@ check_proto_version(struct spoe_frame *frame, char **buf, char *end)
 	DEBUG(frame->worker, "<%lu> Supported versions : %.*s",
 	  frame->client->id, (int)sz, str);
 
-	/* TODO: Find the right verion in supported ones */
+	/* TODO: Find the right version in supported ones */
 
 	ret  = (p - *buf);
 	*buf = p;
diff --git a/contrib/modsecurity/modsec_wrapper.c b/contrib/modsecurity/modsec_wrapper.c
index a3a25414f..7ae831e5c 100644
--- a/contrib/modsecurity/modsec_wrapper.c
+++ b/contrib/modsecurity/modsec_wrapper.c
@@ -140,7 +140,7 @@ int modsecurity_load(const char *file)
 
 	modsec_server = modsecInit();
 	if (modsec_server == NULL) {
-		LOG(_worker, "ModSecurity initilisation failed.\n");
+		LOG(_worker, "ModSecurity initialisation failed.\n");
 		return -1;
 	}
 
@@ -153,7 +153,7 @@ int modsecurity_load(const char *file)
 
 	modsec_config = modsecGetDefaultConfig();
 	if (modsec_config == NULL) {
-		LOG(_worker, "ModSecurity default configuration initilisation failed.\n");
+		LOG(_worker, "ModSecurity default configuration initialisation failed.\n");
 		return -1;
 	}
 
diff --git a/contrib/modsecurity/spoa.c b/contrib/modsecurity/spoa.c
index 225db29f8..20916fdf3 100644
--- a/contrib/modsecurity/spoa.c
+++ b/contrib/modsecurity/spoa.c
@@ -197,7 +197,7 @@ check_proto_version(struct spoe_frame *frame, char **buf, char *end)
 	DEBUG(frame->worker, "<%lu> Supported versions : %.*s",
 	  frame->client->id, (int)sz, str);
 
-	/* TODO: Find the right verion in supported ones */
+	/* TODO: Find the right version in supported ones */
 
 	ret  = (p - *buf);
 	*buf = p;
diff --git a/contrib/plug_qdisc/plug_qdisc.c b/contrib/plug_qdisc/plug_qdisc.c
index 606a834c3..bc47f5d1e 100644
--- a/contrib/plug_qdisc/plug_qdisc.c
+++ b/contrib/plug_qdisc/plug_qdisc.c
@@ -10,7 +10,7 @@
  * XXX Please, first note that this code is not safe. XXX
  * It was developed fast so that to reproduce a bug.
  * You will certainly have to adapt it to your application.
- * But at least it gives an idea about how to programatically use plug
+ * But at least it gives an idea about how to programmatically use plug
  * queueing disciplines.
  */
 
diff --git a/contrib/prometheus-exporter/service-prometheus.c b/contrib/prometheus-exporter/service-prometheus.c
index 6e7eca04b..8ffeb8203 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -73,7 +73,7 @@ enum {
 #define PROMEX_FL_SCOPE_ALL (PROMEX_FL_SCOPE_GLOBAL|PROMEX_FL_SCOPE_FRONT|PROMEX_FL_SCOPE_BACK|PROMEX_FL_SCOPE_SERVER)
 
 /* The max length for metrics name. It is a hard limit but it should be
- * enougth.
+ * enough.
  */
 #define PROMEX_MAX_NAME_LEN 128
 
@@ -615,7 +615,7 @@ const struct ist promex_st_metric_names[ST_F_TOTAL_FIELDS] = {

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

[Emmanuel Hocdet]

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

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

[William Lallemand]

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 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 field of this structure.
> 
> 
> I changed that to be able ro extract the path for « show ssl cert »:
> 
> chain = ckchs->ckch->chain;
> if (chain == NULL) {
>   struct issuer_chain *issuer;
> issuer = ssl_get0_issuer_chain(ckchs->ckch->cert);
> if (issuer) {
> chain = issuer->chain;
> chunk_appendf(out, "Chain Filename: ");
>   chunk_appendf(out, "%s\n", issuer->path);
> }
> }

Hm okay right, I forgot this part. I'm merging the patch, thanks.

-- 
William Lallemand

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

[Emmanuel Hocdet]

> 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 we use the struct issuer_chain only
> to lookup and we only use the chain field of this structure.


I changed that to be able ro extract the path for « show ssl cert »:

chain = ckchs->ckch->chain;
if (chain == NULL) {
struct issuer_chain *issuer;
issuer = ssl_get0_issuer_chain(ckchs->ckch->cert);
if (issuer) {
chain = issuer->chain;
chunk_appendf(out, "Chain Filename: ");
chunk_appendf(out, "%s\n", issuer->path);
}
}

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

[William Lallemand]

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 field of this structure.

> From af21a21caefbcbdcac9aedcd80e952713981e9a8 Mon Sep 17 00:00:00 2001
> From: Emmanuel Hocdet 
> Date: Mon, 23 Mar 2020 11:29:11 +0100
> Subject: [PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to
>  ssl_get0_issuer_chain
> 
> Rename ssl_get_issuer_chain to ssl_get0_issuer_chain to be consistent
> with openssl >= 1.0.2 API.
> ---
>  src/ssl_sock.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 45a650a3d..86fa1a305 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -161,7 +161,7 @@ static struct xprt_ops ssl_sock;
>  int nb_engines = 0;
>  
>  static struct eb_root cert_issuer_tree = EB_ROOT; /* issuers tree from 
> "issuers-chain-path" */
> -static struct issuer_chain* ssl_get_issuer_chain(X509 *cert);
> +static struct issuer_chain* ssl_get0_issuer_chain(X509 *cert);
>  
>  static struct {
>   char *crt_base; /* base directory path for certificates */
> @@ -3629,7 +3629,7 @@ static int ssl_sock_put_ckch_into_ctx(const char *path, 
> const struct cert_key_an
>   } else {
>   /* Find Certificate Chain in global */
>   struct issuer_chain *issuer;
> - issuer = ssl_get_issuer_chain(ckch->cert);
> + issuer = ssl_get0_issuer_chain(ckch->cert);
>   if (issuer)
>   find_chain = issuer->chain;
>   }
> @@ -10166,7 +10166,7 @@ static int ssl_load_global_issuer_from_BIO(BIO *in, 
> char *fp, char **err)
>   return ret;
>  }
>  
> -static struct issuer_chain* ssl_get_issuer_chain(X509 *cert)
> +static struct issuer_chain* ssl_get0_issuer_chain(X509 *cert)
>  {
>   AUTHORITY_KEYID *akid;
>   struct issuer_chain *issuer = NULL;
> @@ -11268,7 +11268,7 @@ static int cli_io_handler_show_cert_detail(struct 
> appctx *appctx)
>   chain = ckchs->ckch->chain;
>   if (chain == NULL) {
>   struct issuer_chain *issuer;
> - issuer = ssl_get_issuer_chain(ckchs->ckch->cert);
> + issuer = ssl_get0_issuer_chain(ckchs->ckch->cert);
>   if (issuer) {
>   chain = issuer->chain;
>   chunk_appendf(out, "Chain Filename: ");





-- 
William Lallemand

[PATCH] CLEANUP: ssl: rename ssl_get_issuer_chain to ssl_get0_issuer_chain

[Emmanuel Hocdet]

As discussed in #559



0001-CLEANUP-ssl-rename-ssl_get_issuer_chain-to-ssl_get0_.patch
Description: Binary data

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

[Kiran Gavali]

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 review the patch and provide your feedback.

Regards
Kiran Gavali

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: Monday, February 24, 2020 1:26 PM
To: Kiran Gavali 
Subject: Re: HAProxy v2.1.0 health checks with POST and data corrupted by extra 
"connection: close"

Hello Kiran,

On Mon, Feb 24, 2020 at 07:00:08AM +, Kiran Gavali wrote:
> Hello Mr. Willy Tarreau ,
>
> Issue Link: https://github.com/haproxy/haproxy/issues/16

Oh I didn't notice that you've updated the report there a month ago, sorry 
about that, I get so many github notifications that I do miss quite some of 
them :-(

> I have reproduced and analyzed the above bug on HAProxy v2.1.0 (using 
> Wireshark).
> As per my findings, the "Connection: close" string is appended after
> the data block instead of being appended after the header. [Refer the
> attached Wireshark screenshot at the end]

Yes absolutely, that's the problem (and limitation) described there.

> As stated by @wtarreau in [
> #https://www.mail-archive.com/haproxy@formilux.org/msg28200.html], it
> would be best to add another option "body" to http-check directive so
> as to correctly differentiate body from header, as shown below:-
>
> option httpchk POST / HTTP/1.1\r\n
> http-check header Host: 10.10.26.236\r\nContent-Type:
> application/json\r\nContent-Length: 38\r\n http-check body
> {"command":"getNodeInfo"} http-check expect rstatus (2|3)[0-9][0-9]
>
> To incorporate the change, we need to do changes in below code:-
> File: cfgparse-listen.c
> Function: int cfg_parse_listen(const char *file, int linenum, char
> **args, int kwm) Code Snippet: curproxy->check_len =
> snprintf(curproxy->check_req, reqlen, "%s %s %s\r\n", args[2],
> args[3], *args[4]?args[4]:"HTTP/1.0");
>
> Please let me know if my understanding of the above issue is correct,
> so that I can proceed further accordingly. Looking forward for your guidance.

Your analysis is correct. However this issue is more than two years old now and 
the check system is currently being reworked in order to support muxes for 
HTTP/1 and HTTP/2 so that we have better checks in 2.2. However I don't know if 
for this specific issue we can come up with something trivial enough to be 
backported to older releases with no risk at all.
I guess that it might be worth trying, but let me be clear about the fact that 
if the code becomes tricky, we may finally decide not to merge it and/or not to 
backport it.

Do not hesitate to share your findings on the mailing list so that others can 
follow the progress and possibly suggest adjustments.

Thanks!
Willy

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. It shall not attach any liability on 
the originator or NECTI or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the 
opinions of NECTI or its affiliates. Any form of reproduction, dissemination, 
copying, disclosure, modification, distribution and / or publication of this 
message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have received this email in error please delete it 
and notify the sender immediately.


0001-resolving-bug-of-health-checks-with-POST-and-data-co.patch
Description:  0001-resolving-bug-of-health-checks-with-POST-and-data-co.patch

Re: [PATCH] fix memory leak, issue 559

[William Lallemand]

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 #559
> > 
> 
> ++
> Manu
> 

Thanks Manu, merged.



-- 
William Lallemand

Re: Peers Protocol "Table Type"

[Emeric Brun]

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 pas dutout sur 
du haproxy en ce moment, alors j'espère qu'il n'y a pas urgence sur ce point ca 
m'arrangerait de m'en occuper qu'après.

Emeric

Re: [PATCH] fix memory leak, issue 559

[Emmanuel Hocdet]

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
Description: Binary data

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

[Martin Grigorov]

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 not "travis_wait 30" instead of "travis_wait")
>

it is running at the moment here:
https://travis-ci.org/github/martin-g/haproxy/builds/665770469


>
>
> also, it might be important to clear travis cache from time to time.
> as for myself, "travis_wait 30" helped me to resolve similar issue on
> another project (in my own fork haproxy on arm64 builds just fine)
>
> ср, 18 мар. 2020 г. в 23:35, Илья Шипицин :
>
>> well, there are several topics on travis-ci forum related to "output on
>> ARM64 got truncated in the mid of ..."
>> Let us disable ARM64 travis-ci builds for few months.
>>
>> Martin, I'll play with hosted github runner in order to find a way how we
>> can limit its builds to allowed only.
>>
>> ср, 18 мар. 2020 г. в 18:57, Martin Grigorov :
>>
>>>
>>> Current master's build passed the problematic point in my TravisCI
>>> project: https://travis-ci.org/github/martin-g/haproxy/jobs/663953359
>>> Note: I use TravisCI .org while HAProxy's official project is at .com:
>>> https://travis-ci.com/github/haproxy/haproxy
>>> I also think this is a problem on TravisCI's end.
>>>
>>> Martin
>>>
>>> On Wed, Mar 18, 2020 at 3:43 PM Илья Шипицин 
>>> wrote:
>>>
 I will disable PR builds.

 On Wed, Mar 18, 2020, 6:27 PM Willy Tarreau  wrote:

> On Wed, Mar 18, 2020 at 06:21:15PM +0500,  ??? wrote:
> > let us calm down a bit :)
>
> Agreed, especially since the build on PRs already happens and already
> adds noise.
>
> > yes, I still believe it is because of buffering. I might have missed
> > something.
> > unless I will repair it, I'll drop arm64 support on travis (and we
> will
> > switch to self hosted github action runner)
>
> OK.
>
> Willy
>

[ANNOUNCE] haproxy-2.2-dev5

[Willy Tarreau]

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 received in the PROXY protocol
for connection tracing purposes along a chain. This is mostly useful
for TCP-based protocols since in HTTP it may already be done with
HTTP headers.

  - the default maxconn used to appear as lower than before for a number
of users, because before 2.0 it used to be hard-coded to 2000 (even
if FD limits were too low) and now we used to rely on the soft limit
instead of the hard limit. This made haproxy use the least possible
FDs as the upper bound. Now instead we rely on the hard limit, which
makes more sense since the goal is to allow what's permitted. This
will increase the default maxconn for users who don't set it and who
don't touch their FD limit using "ulimit -n" on the command line.

  - it's possible to dump the crt-lists from the command line using
"show crt-list" or "dump crt-list".

  - there's now the possibility to create an SSL certificate directly
from the command line ("new ssl cert") though the commit message
suggests some parts are still missing for it to be completely usable
with crt-lists, which also hints why it doesn't appear yet in the
doc so I don't know if I ought to speak about it or not :-)

  - idle server connections may now be reused between threads. This
should significantly reduce the number of file descriptors for
setups using a large number of threads, and significantly increase
the reuse rate. Please not that this applies to *idle* connections
(i.e. not used at all). Multiplexed connections like H2 or FCGI
may still be used by a single thread at once, eventhough any thread
can pick them first (but there are theorical plans to try to share
them in 2.3).

We're approaching the end of unplanned changes, so the goal will now be
to mostly focus on finishing what's already started. Regarding the
pending stuff I currently have in mind, I think there are still changes
coming on the SSL side regarding runtime certificate management, there
are pending changes on health checks to clean the horrible mess we have
accumulated since 1.1, and I made one quick attempt at implementing TCP
logs but I figured that it required one hour of work and probably one
week of code refactoring bringing no value except avoiding code
duplication, and I must confess I lost my motivation. We need to find
the sweet spot between reworking the logs at the last minute and making
sure we do something quick but forward-compatible from a configuration
perspective. A few more improvements on FD management and idle connections
are expected as well. If you have pending stuff on your side that you'd
like to see merged in 2.2, please at least speak about it now, because
code review takes a huge amount of time and those currently finishing
their work cannot always be available to review some late changes.

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Sources  : http://www.haproxy.org/download/2.2/src/
   Git repository   : http://git.haproxy.org/git/haproxy.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy.git
   Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Balvinder Singh Rawat (1):
  DOC: correct typo in alert message about rspirep

David Carlier (1):
  BUILD: on ARM, must be linked to libatomic.

Emeric Brun (1):
  BUG/MEDIUM: peers: resync ended with RESYNC_PARTIAL in wrong cases.

Ilya Shipitsin (7):
  CLEANUP: assorted typo fixes in the code and comments
  CI: add spellcheck github action
  CI: travis: switch linux builds to clang-9
  CI: travis: proper group output redirection together with travis_wait
  DOC: assorted typo fixes in the documentation
  CI: run travis-ci builds on push only, skip pull requests
  CI: temporarily disable unstable travis arm64 builds

Kevin Zhu (1):
  BUG/MEDIUM: spoe: dup agent's engine_id string from trash.area

Lukas Tribus (1):
  DOC: ssl: clarify security implications of TLS tickets

Olivier Houchard (33):
  BUG/MINOR: buffers: MT_LIST_DEL_SAFE() expects the temporary pointer.
  BUG/MEDIUM: mt_lists: Make sure we set the deleted element to NULL;
  MINOR: mt_lists: Appease gcc.
  MINOR: lists: Implement function to convert list => mt_list and mt_list 
=> list
  MINOR: servers: Kill priv_conns.
  MINOR: lists: fix indentation.
  BUG/MEDIUM: connections: Don't assume 

Re: regtest: abns should work now :-)

[Willy Tarreau]

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

Re: regtest: abns should work now :-)

[Martin Grigorov]

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 with memory aligning".
> also, I tried to run arm64 emulation on virtualbox. no luck yet.
>

Have you tried with multiarch Docker ?

1) execute
docker run --rm --privileged multiarch/qemu-user-static:register --reset
to register QEMU

2) create Dockerfile
for Centos use: FROM multiarch/centos:7-aarch64-clean
for Ubuntu use: FROM multiarch/ubuntu-core:arm64-bionic

3) enjoy :-)


>
> пн, 23 мар. 2020 г. в 13:43, Willy Tarreau :
>
>> 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
>> the commit which relaxed the maxconn limitations. A starting process
>> stealing a few ms of CPU from the old one could make its keep-alive
>> timeout expire before it got a new request on a reused connection,
>> resulting in an empty response as reported by the client.
>>
>> I'm going to issue dev5 now. s390x is currently down but all x86 ones
>> build and run fine for now.
>>
>> Cheers,
>> Willy
>>
>

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 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
> the commit which relaxed the maxconn limitations. A starting process
> stealing a few ms of CPU from the old one could make its keep-alive
> timeout expire before it got a new request on a reused connection,
> resulting in an empty response as reported by the client.
>
> I'm going to issue dev5 now. s390x is currently down but all x86 ones
> build and run fine for now.
>
> Cheers,
> Willy
>

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 luck yet.

пн, 23 мар. 2020 г. в 13:43, Willy Tarreau :

> 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
> the commit which relaxed the maxconn limitations. A starting process
> stealing a few ms of CPU from the old one could make its keep-alive
> timeout expire before it got a new request on a reused connection,
> resulting in an empty response as reported by the client.
>
> I'm going to issue dev5 now. s390x is currently down but all x86 ones
> build and run fine for now.
>
> Cheers,
> Willy
>

regtest: abns should work now :-)

[Willy Tarreau]

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
the commit which relaxed the maxconn limitations. A starting process
stealing a few ms of CPU from the old one could make its keep-alive
timeout expire before it got a new request on a reused connection,
resulting in an empty response as reported by the client.

I'm going to issue dev5 now. s390x is currently down but all x86 ones
build and run fine for now.

Cheers,
Willy