Re: Haproxy 1.8 version help

[Willy Tarreau]

On Thu, Jan 04, 2018 at 12:30:47PM +0530, Devendra Joshi wrote:
> Hi Lukas n Willy,
> 
> Its working fine with add on of this option *USE_THREAD=*
> 
> Can you tell me why to disable thread support,
> will this impact on my haproxy or my server ?

No it will not at all. Threads are still experimental and were added
in version 1.8. The expectation is that over time it will allow us to
provde almost the same level of performance as what we currently have
with multi-processes, but without the trouble caused by multi-process.

Regards,
Willy

Re: Haproxy 1.8 version help

[Devendra Joshi]

Hi Lukas n Willy,

Its working fine with add on of this option *USE_THREAD=*

Can you tell me why to disable thread support,
will this impact on my haproxy or my server ?



Devendra Joshi
8080106035
--
--


On 4 January 2018 at 11:20, Devendra Joshi 
wrote:

> Hi Willy and Lukas,
>
> I tried with the solution which provided by Lukas,
>
> the same error i found on console.
>
>
>
>
>
>
> Devendra Joshi
> 8080106035 <080801%2006035>
> --
> --
>
>
> On 4 January 2018 at 02:34, Willy Tarreau  wrote:
>
>> On Wed, Jan 03, 2018 at 05:39:50PM +0100, Lukas Tribus wrote:
>> > > src/hathreads.o: In function `thread_want_sync':
>> > > /softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
>> > > `__atomic_or_fetch'
>> > > src/hathreads.o: In function `thread_exit_sync':
>> > > /softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
>> > > `__atomic_and_fetch'
>> > > src/hathreads.o: In function `thread_sync_barrier':
>> > > /softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
>> > > `__atomic_compare_exchange_n'
>> > > /softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
>> > > `__atomic_or_fetch'
>> > > src/lb_map.o: In function `recalc_server_map':
>> > > /softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
>> > > `__atomic_add_fetch'
>> > > /softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
>> > > `__atomic_sub_fetch'
>> > > src/compression.o: In function `deinit_comp_ctx':
>> > > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference
>> to
>> > > `__atomic_sub_fetch'
>> > > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference
>> to
>> > > `__atomic_sub_fetch'
>> > > src/compression.o: In function `init_comp_ctx':
>> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference
>> to
>> > > `__atomic_add_fetch'
>> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference
>> to
>> > > `__atomic_add_fetch'
>> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference
>> to
>> > > `__atomic_add_fetch'
>> > > src/compression.o: In function `alloc_zlib':
>> > > /softwares/haproxy-1.8.2/src/compression.c:469: undefined reference
>> to
>> > > `__atomic_add_fetch'
>> > > src/compression.o: In function `free_zlib':
>> > > /softwares/haproxy-1.8.2/src/compression.c:500: undefined reference
>> to
>> > > `__atomic_sub_fetch'
>> > > src/time.o: In function `tv_update_date':
>> > > /softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
>> > > `__atomic_compare_exchange_n'
>> > > collect2: ld returned 1 exit status
>> > > make: *** [haproxy] Error 1
>> >
>> >
>> > To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
>> > CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
>>
>> If these are the only failures, maybe we can try and see if we find
>> equivalent builtins for older versions. I seem to remember that most
>> of them have their equivalent with the __sync_* builtins on older
>> compilers, but there was something odd with the compare_and_swap(),
>> only allowing a few bits to be used or something like this.
>>
>> I've always been all for supporting older compilers exactly for the
>> reason above. Till very recently, gcc-2.95 was still reported to work ;-)
>>
>> Willy
>>
>
>

Re: Haproxy 1.8 version help

[Willy Tarreau]

On Wed, Jan 03, 2018 at 11:50:28PM +0100, Lukas Tribus wrote:
> > I've always been all for supporting older compilers exactly for the
> > reason above. Till very recently, gcc-2.95 was still reported to work ;-)
> 
> I also have to say that I consider thread support to be a
> "high-performance" feature, and I would not personally consider
> pairing such high-performance features with a obsolete OS like CentOs
> 6. I mean ... we are talking linux 2.6.32 (I heard even 2.6.32's
> maintainer pulled the plug last year :) )

Sure but the same can be said for other operating systems as well.
CentOS 6 is still supported by its vendor (till end of 2020) so unless
we have a good reason (technical difficulty, incompatibility, etc), we
should at least check if it can be done. For me the only reason is that
the newer version of the atomic_* builtins were used while we used to
use the older version in the shctx code. It's very possible the older
version doesn't exist anymore in newer compilers. But if it's just a
matter of adding a #ifdef, it will not take a long time to check.

> The reason we see this build failure is that we implicitly added
> USE_THREADS=1 in the linux2628 make target. Perhaps we just need a new
> make target with something more recent and move threads support to it.
> However it's also true that without implicitly enabling threads in the
> linux2628 target we would have never seen the amount of feedback for
> thread issues that we saw, and most of the bugs would probably still
> be unfixed at this point.

Exactly. I'd rather encourage everyone to enable all features by default
so that we can add options to disable what is known broken, than slowly
discovering what works and making people believe there are few features.

> In any case, I would avoid complicating the codebase and/or investing
> a lot of time to bring thread support to CentOS 6, I'd rather keep it
> simple and disable thread support for it by default (whether via
> different make targets or by other means).

I totally agree and my point really is not to make anything complicated
nor to take risks. Oh and now I have a good incentive to look at this,
my home NFS server also runs gcc 4.4 and doesn't build threads ;-)

Willy

Re: [PR] avoid overriding external prefix

[Илья Шипицин]

2018-01-04 2:13 GMT+05:00 Willy Tarreau :

> Hi Stephen,
>
> On Wed, Jan 03, 2018 at 08:33:14PM +0100, PR Bot wrote:
> > Dear list!
> >
> > Author: Stephen 
> > Number of patches: 1
> >
> > This is an automated relay of the Github pull request:
> >avoid overriding external prefix
> >
> > Patch title(s):
> >avoid overriding external prefix
> >
> > Link:
> >https://github.com/haproxy/haproxy/pull/82
>
> From d14f3c9d806bfe6e6b7e1fb81ab9973b04d2736a Mon Sep 17 00:00:00 2001
> From: Stephen 
> Date: Wed, 3 Jan 2018 09:28:35 -0800
> Subject: [PATCH] avoid overriding external prefix
>
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 8927919b..755503d4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -91,7 +91,7 @@
>
>   Installation options.
>  DESTDIR =
> -PREFIX = /usr/local
> +PREFIX ?= /usr/local
>  SBINDIR = $(PREFIX)/sbin
>  MANDIR = $(PREFIX)/share/man
>  DOCDIR = $(PREFIX)/doc/haproxy
>
> I'm wondering why it is that over the last few weeks we received a few
> such wrong patches while we never had them in 15 years. Maybe we need
> to add a few lines to the makefile explaining how to use a makefile and
> why it's *always* wrong to use "?=" (it inherits whatever randomly lies
> in your environment).
>

if it is wrong, why is it used almost everywhere :)

# find . -name Makefile -exec grep '?=' {} ';' -print
CC ?= gcc
./Makefile
CC   ?= gcc
./contrib/tcploop/Makefile
CC   ?= gcc
./contrib/iprange/Makefile
CC ?= gcc
CXX ?= g++
./contrib/mod_defender/Makefile
CC ?= gcc
./contrib/spoa_example/Makefile
CC  ?= gcc
./contrib/debug/Makefile
CC   ?= gcc
./contrib/halog/Makefile
CC ?= gcc
./contrib/modsecurity/Makefile
CC   ?= gcc
./contrib/ip6range/Makefile




>
> Please have a look at the longer explanation I sent here a few days ago :
>
>https://www.mail-archive.com/haproxy@formilux.org/msg28390.html
>
> Thanks,
> Willy
>
>

Re: Haproxy 1.8 version help

[Devendra Joshi]

Hi Willy and Lukas,

I tried with the solution which provided by Lukas,

the same error i found on console.






Devendra Joshi
8080106035
--
--


On 4 January 2018 at 02:34, Willy Tarreau  wrote:

> On Wed, Jan 03, 2018 at 05:39:50PM +0100, Lukas Tribus wrote:
> > > src/hathreads.o: In function `thread_want_sync':
> > > /softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
> > > `__atomic_or_fetch'
> > > src/hathreads.o: In function `thread_exit_sync':
> > > /softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
> > > `__atomic_and_fetch'
> > > src/hathreads.o: In function `thread_sync_barrier':
> > > /softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
> > > `__atomic_compare_exchange_n'
> > > /softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
> > > `__atomic_or_fetch'
> > > src/lb_map.o: In function `recalc_server_map':
> > > /softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
> > > `__atomic_add_fetch'
> > > /softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
> > > `__atomic_sub_fetch'
> > > src/compression.o: In function `deinit_comp_ctx':
> > > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > > `__atomic_sub_fetch'
> > > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > > `__atomic_sub_fetch'
> > > src/compression.o: In function `init_comp_ctx':
> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > > `__atomic_add_fetch'
> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > > `__atomic_add_fetch'
> > > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > > `__atomic_add_fetch'
> > > src/compression.o: In function `alloc_zlib':
> > > /softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
> > > `__atomic_add_fetch'
> > > src/compression.o: In function `free_zlib':
> > > /softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
> > > `__atomic_sub_fetch'
> > > src/time.o: In function `tv_update_date':
> > > /softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
> > > `__atomic_compare_exchange_n'
> > > collect2: ld returned 1 exit status
> > > make: *** [haproxy] Error 1
> >
> >
> > To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
> > CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
>
> If these are the only failures, maybe we can try and see if we find
> equivalent builtins for older versions. I seem to remember that most
> of them have their equivalent with the __sync_* builtins on older
> compilers, but there was something odd with the compare_and_swap(),
> only allowing a few bits to be used or something like this.
>
> I've always been all for supporting older compilers exactly for the
> reason above. Till very recently, gcc-2.95 was still reported to work ;-)
>
> Willy
>

Re: Haproxy 1.8 version help

[Ramin K]

On 1/3/18 10:10 AM, Philipp Buehler wrote:

Am 03.01.2018 17:39 schrieb Lukas Tribus:

To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
CentOs 6 only ships GCC 4.4.7, therefor compilation fails.


Waaah, thanks for telling before I tried to rush 1.8 to customer :-P

Rather not in the mood to make a build-VM with 4.7+ on C6 .. :-}
*hint*

ciao


Can always install devtoolset-6, 
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/ which 
installs off the side. Enable it in a shell and you should be good to go.


Ramin

Re: Haproxy 1.8 version help

[Lukas Tribus]

Hi Willy,


On Wed, Jan 3, 2018 at 10:04 PM, Willy Tarreau  wrote:
>> To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
>> CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
>
> If these are the only failures, maybe we can try and see if we find
> equivalent builtins for older versions. I seem to remember that most
> of them have their equivalent with the __sync_* builtins on older
> compilers, but there was something odd with the compare_and_swap(),
> only allowing a few bits to be used or something like this.

Yes, I believe it's only about those atomic functions that have been
introduced in GCC4.7. If this is a rather easy thing to do with no
particular impact, sure, I agree, but ...


> I've always been all for supporting older compilers exactly for the
> reason above. Till very recently, gcc-2.95 was still reported to work ;-)

I also have to say that I consider thread support to be a
"high-performance" feature, and I would not personally consider
pairing such high-performance features with a obsolete OS like CentOs
6. I mean ... we are talking linux 2.6.32 (I heard even 2.6.32's
maintainer pulled the plug last year :) )

The reason we see this build failure is that we implicitly added
USE_THREADS=1 in the linux2628 make target. Perhaps we just need a new
make target with something more recent and move threads support to it.
However it's also true that without implicitly enabling threads in the
linux2628 target we would have never seen the amount of feedback for
thread issues that we saw, and most of the bugs would probably still
be unfixed at this point.


In any case, I would avoid complicating the codebase and/or investing
a lot of time to bring thread support to CentOS 6, I'd rather keep it
simple and disable thread support for it by default (whether via
different make targets or by other means).


cheers,
lukas

Quick question on HA Proxy cluster management

[Muthukumar Srinivasan - Consultant]

Dear Sir

I am looking for HA Proxy cluster management open source. we have over 100
HA Proxy instances used for Load balancing, SSL termination etc. we need to
manage all of them in one unified place.


let me know if you have any products

thank you

-- 
Thank you
Muthukumar Srinivasan
Enterprise Architect for DevOps, CloudOps and Analytics.
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of 
the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify 
us immediately at 262-703-7000.

CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the 
right to retrieve and read any message created, sent and received. Kohl's 
reserves the right to monitor messages by authorized Kohl's Associates at any 
time
without any further consent.

Re: 1.8.3: Slow posts on H2 (IE only?)

[Peter Lindegaard Hansen]

Hi,

What a quick response on this issue :)

I will try to apply the patch (i am no expert at this) and see the results.
I did find another h2-related issue, but where unable to pinpoint exactly
why as it where deep in ajax application, but i will see with this patch if
its the same issue.





Med venlig hilsen


*Peter Lindegaard Hansen*

*Softwareudvikler / Partner*

Telefon: +45 96 500 300 | Direkte: 69 14 97 04 | Email: p...@tigermedia.dk
Tiger Media A/S | Gl. Gugvej 17C | 9000 Aalborg | Web: www.tigermedia.dk

For supportspørgsmål kontakt os da på supp...@tigermedia.dk eller på tlf.
96 500 300
og din henvendelse vil blive besvaret af første ledige medarbejder.

2018-01-03 22:34 GMT+01:00 Lukas Tribus :

> Hello,
>
>
> On Wed, Jan 3, 2018 at 9:51 PM, Willy Tarreau  wrote:
> > On Wed, Jan 03, 2018 at 09:31:47PM +0100, Willy Tarreau wrote:
> >> Oh I think you've just put your finger on it. I remember taking care
> >> of handling 0-sized frames, and facing certain difficulties with them
> >> (eg: sometimes returning size 0 just means nothing was done). I sounds
> >> very likely that we can still have a bug around this. It would also
> >> explain why your patch could get rid of it.
> >>
> >> I'll have a look at the code in case I have an idea.
> >
> > Could you please try the attached patch? I'm pretty sure it is *very*
> > related to your observations. In fact till now we would not update the
> > parser's state on an empty data frame, which explains why you had to
> > move the stuff around.
>
> Yes, I can confirm this fixes the problem for me, and in a good
> looking way too: all streams are correctly handled within that single
> connection (no sudden connection teardown and subsequent new
> connection for follow-up streams).
>
> Now we won't even bother the ML subscribers with a 50+ messages
> mega-thread debugging an obscure H2 issue :)
>
>
> regards,
> lukas
>

Re: 1.8.3: Slow posts on H2 (IE only?)

[Lukas Tribus]

Hello,


On Wed, Jan 3, 2018 at 9:51 PM, Willy Tarreau  wrote:
> On Wed, Jan 03, 2018 at 09:31:47PM +0100, Willy Tarreau wrote:
>> Oh I think you've just put your finger on it. I remember taking care
>> of handling 0-sized frames, and facing certain difficulties with them
>> (eg: sometimes returning size 0 just means nothing was done). I sounds
>> very likely that we can still have a bug around this. It would also
>> explain why your patch could get rid of it.
>>
>> I'll have a look at the code in case I have an idea.
>
> Could you please try the attached patch? I'm pretty sure it is *very*
> related to your observations. In fact till now we would not update the
> parser's state on an empty data frame, which explains why you had to
> move the stuff around.

Yes, I can confirm this fixes the problem for me, and in a good
looking way too: all streams are correctly handled within that single
connection (no sudden connection teardown and subsequent new
connection for follow-up streams).

Now we won't even bother the ML subscribers with a 50+ messages
mega-thread debugging an obscure H2 issue :)


regards,
lukas

Re: [PR] avoid overriding external prefix

[Willy Tarreau]

Hi Stephen,

On Wed, Jan 03, 2018 at 08:33:14PM +0100, PR Bot wrote:
> Dear list!
> 
> Author: Stephen 
> Number of patches: 1
> 
> This is an automated relay of the Github pull request:
>avoid overriding external prefix
> 
> Patch title(s): 
>avoid overriding external prefix
> 
> Link:
>https://github.com/haproxy/haproxy/pull/82

>From d14f3c9d806bfe6e6b7e1fb81ab9973b04d2736a Mon Sep 17 00:00:00 2001
From: Stephen 
Date: Wed, 3 Jan 2018 09:28:35 -0800
Subject: [PATCH] avoid overriding external prefix

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8927919b..755503d4 100644
--- a/Makefile
+++ b/Makefile
@@ -91,7 +91,7 @@
 
  Installation options.
 DESTDIR =
-PREFIX = /usr/local
+PREFIX ?= /usr/local
 SBINDIR = $(PREFIX)/sbin
 MANDIR = $(PREFIX)/share/man
 DOCDIR = $(PREFIX)/doc/haproxy

I'm wondering why it is that over the last few weeks we received a few
such wrong patches while we never had them in 15 years. Maybe we need
to add a few lines to the makefile explaining how to use a makefile and
why it's *always* wrong to use "?=" (it inherits whatever randomly lies
in your environment).

Please have a look at the longer explanation I sent here a few days ago :

   https://www.mail-archive.com/haproxy@formilux.org/msg28390.html

Thanks,
Willy

Re: [PATCH] BUILD/SMALL Fixed build on macOS with lua

[Willy Tarreau]

Hi Kirill,

On Thu, Dec 28, 2017 at 04:13:38AM +0400, Kirill A. Korinsky wrote:
> Last macOS hasn't support export-dynamic, just remove it
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 2acf5028..19234897 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -630,7 +630,7 @@ check_lua_inc = $(shell if [ -d $(2)$(1) ]; then echo 
> $(2)$(1); fi;)
>  
>  BUILD_OPTIONS   += $(call ignore_implicit,USE_LUA)
>  OPTIONS_CFLAGS  += -DUSE_LUA $(if $(LUA_INC),-I$(LUA_INC))
> -LUA_LD_FLAGS := -Wl,--export-dynamic $(if $(LUA_LIB),-L$(LUA_LIB))
> +LUA_LD_FLAGS := $(if $(LUA_LIB),-L$(LUA_LIB))

Hmmm how can you be sure you didn't break anything else ? I'm pretty
sure that there was a reason for adding this --export-dynamic, maybe
certain things will still not work on your platform, or others won't
work at all. We need to run some checks before taking this one.

I'm CCing Thierry in case he reminds why we need this.

Regards,
Willy

Re: Haproxy 1.8 version help

[Willy Tarreau]

On Wed, Jan 03, 2018 at 05:39:50PM +0100, Lukas Tribus wrote:
> > src/hathreads.o: In function `thread_want_sync':
> > /softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
> > `__atomic_or_fetch'
> > src/hathreads.o: In function `thread_exit_sync':
> > /softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
> > `__atomic_and_fetch'
> > src/hathreads.o: In function `thread_sync_barrier':
> > /softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
> > `__atomic_compare_exchange_n'
> > /softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
> > `__atomic_or_fetch'
> > src/lb_map.o: In function `recalc_server_map':
> > /softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
> > `__atomic_sub_fetch'
> > src/compression.o: In function `deinit_comp_ctx':
> > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > `__atomic_sub_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > `__atomic_sub_fetch'
> > src/compression.o: In function `init_comp_ctx':
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > src/compression.o: In function `alloc_zlib':
> > /softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
> > `__atomic_add_fetch'
> > src/compression.o: In function `free_zlib':
> > /softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
> > `__atomic_sub_fetch'
> > src/time.o: In function `tv_update_date':
> > /softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
> > `__atomic_compare_exchange_n'
> > collect2: ld returned 1 exit status
> > make: *** [haproxy] Error 1
> 
> 
> To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
> CentOs 6 only ships GCC 4.4.7, therefor compilation fails.

If these are the only failures, maybe we can try and see if we find
equivalent builtins for older versions. I seem to remember that most
of them have their equivalent with the __sync_* builtins on older
compilers, but there was something odd with the compare_and_swap(),
only allowing a few bits to be used or something like this.

I've always been all for supporting older compilers exactly for the
reason above. Till very recently, gcc-2.95 was still reported to work ;-)

Willy

Re: 1.8.3: Slow posts on H2 (IE only?)

[Willy Tarreau]

On Wed, Jan 03, 2018 at 09:31:47PM +0100, Willy Tarreau wrote:
> Oh I think you've just put your finger on it. I remember taking care
> of handling 0-sized frames, and facing certain difficulties with them
> (eg: sometimes returning size 0 just means nothing was done). I sounds
> very likely that we can still have a bug around this. It would also
> explain why your patch could get rid of it.
> 
> I'll have a look at the code in case I have an idea.

Could you please try the attached patch? I'm pretty sure it is *very*
related to your observations. In fact till now we would not update the
parser's state on an empty data frame, which explains why you had to
move the stuff around.

Thanks!
Willy
diff --git a/src/mux_h2.c b/src/mux_h2.c
index c6e15ec..6348826 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -2770,7 +2770,7 @@ static int h2_frt_transfer_data(struct h2s *h2s, struct 
buffer *buf, int count)
 
flen = h2c->dfl - h2c->dpl;
if (!flen)
-   return 0;
+   goto end_transfer;
 
if (flen > h2c->dbuf->i) {
flen = h2c->dbuf->i;
@@ -2817,6 +2817,7 @@ static int h2_frt_transfer_data(struct h2s *h2s, struct 
buffer *buf, int count)
return flen;
}
 
+end_transfer:
/* here we're done with the frame, all the payload (except padding) was
 * transferred.
 */

Re: 1.8.3: Slow posts on H2 (IE only?)

[Willy Tarreau]

On Wed, Jan 03, 2018 at 09:07:35PM +0100, Lukas Tribus wrote:
> When the client sends the POST, haproxy responds with the 302 from the
> backend (stream 3), the client follows the redirect sending a the new
> GET (stream 5) which haproxy never sees. However, with this patch,
> haproxy also sends GOAWAY (Last-Stream-ID = 3) and the entire
> connection is killed. Because the browser understands that stream 5
> was never considered, the browser recovers from this situation by
> resending the GET request in a new connection immediately.

OK I understand, thus in fact it "hides" the problem.

> Before my patch, after the the 302 redirect in stream 3, and the GET
> request in stream 5, the connection basically hangs, and haproxy
> doesn't 'see' stream 5 and the browser waits for a response, until
> haproxy kills the connection (due to timeout).

Interesting. It could indicate that haproxy is stuck in the FRAME_P state
waiting for the data of the initial stream and for some reason never
escapes.

> I took a look of the behavior of Edge compared to other, unaffected
> browsers and one thing caught my attention:
> Edge sends 2 DATA frames, the first one with the actual POST data (no
> ES bit set), the second DATA frame is empty (Length: 0) and has the ES
> bit set. All other browsers just have one single DATA frame with both
> the payload and the ES bit set. I assume the 0-length DATA frame may
> be something haproxy is unable to handle and brings the entire
> connection into a bogus state?

Oh I think you've just put your finger on it. I remember taking care
of handling 0-sized frames, and facing certain difficulties with them
(eg: sometimes returning size 0 just means nothing was done). I sounds
very likely that we can still have a bug around this. It would also
explain why your patch could get rid of it.

I'll have a look at the code in case I have an idea.

Thanks!
Willy

Re: 1.8.3: Slow posts on H2 (IE only?)

[Lukas Tribus]

Hello,


On Wed, Jan 3, 2018 at 5:56 PM, Willy Tarreau  wrote:
>> When moving the affected HREM code above the "return 0" branch, Edge
>> works fine again.
>>
>> The attached patch fixes the issue for me, please give it a try.
>
> The problem with doing this is that when we have to stop transferring
> data because for example the target buffer is full, we'll still switch
> to HREM anyway and randomly destroy the last data frame. It was one of
> the reasons some uploads were randomly truncated.
>
> But if it fixes the issue for you, it may indicate we're not properly
> woken up sometimes during the upload. If I understand well, it only
> happens on redirects, so maybe one transition is causing trouble here,
> typically we may have an HLOC state (half-close(local)) when the response
> is sent by the server before the client finishes to upload, and it's
> possible that we don't continue to drain pending data there. With
> your change it likely causes the stream to be aborted on this last
> frame, unblocking the situation. That's just a wild guess, as usual :-/

In fact, with my patch the situation is not desirable at all:

When the client sends the POST, haproxy responds with the 302 from the
backend (stream 3), the client follows the redirect sending a the new
GET (stream 5) which haproxy never sees. However, with this patch,
haproxy also sends GOAWAY (Last-Stream-ID = 3) and the entire
connection is killed. Because the browser understands that stream 5
was never considered, the browser recovers from this situation by
resending the GET request in a new connection immediately.

Before my patch, after the the 302 redirect in stream 3, and the GET
request in stream 5, the connection basically hangs, and haproxy
doesn't 'see' stream 5 and the browser waits for a response, until
haproxy kills the connection (due to timeout).


I took a look of the behavior of Edge compared to other, unaffected
browsers and one thing caught my attention:
Edge sends 2 DATA frames, the first one with the actual POST data (no
ES bit set), the second DATA frame is empty (Length: 0) and has the ES
bit set. All other browsers just have one single DATA frame with both
the payload and the ES bit set. I assume the 0-length DATA frame may
be something haproxy is unable to handle and brings the entire
connection into a bogus state?


Regards,
Lukas

[PR] avoid overriding external prefix

[PR Bot]

Dear list!

Author: Stephen 
Number of patches: 1

This is an automated relay of the Github pull request:
   avoid overriding external prefix

Patch title(s): 
   avoid overriding external prefix

Link:
   https://github.com/haproxy/haproxy/pull/82

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/82.patch && vi 82.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/82.patch | git am -

Description:


Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re: HAProxy 1.8.3 SSL caching regression

[Jeffrey J. Persch]

Hi William,

The test case now works. I will do load testing with the patch today.

Thanks,
Jeffrey J. Persch

On Wed, Jan 3, 2018 at 1:25 PM, William Lallemand 
wrote:

> On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote:
> > I'm able to reproduce the problem thanks to your detailed example, it
> looks
> > like a regression in the code.
> >
> > I will check the code to see what's going on.
>
> I found the issue, would you mind trying the attached patch?
>
> Thanks.
>
> --
> William Lallemand
>

Re: HAProxy 1.8.3 SSL caching regression

[William Lallemand]

On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote:
> I'm able to reproduce the problem thanks to your detailed example, it looks
> like a regression in the code.
> 
> I will check the code to see what's going on.

I found the issue, would you mind trying the attached patch?

Thanks.

-- 
William Lallemand
>From da786103ff39a0bed8efbde120808b2ee2ec Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Wed, 3 Jan 2018 19:15:51 +0100
Subject: [PATCH] BUG/MEDIUM: ssl: cache doesn't release shctx blocks

Since the rework of the shctx with the hot list system, the ssl cache
was putting session inside the hot list, without removing them.
Once all block were used, they were all locked in the hot list, which
was forbiding to reuse them for new sessions.

Bug introduced by 4f45bb9 ("MEDIUM: shctx: separate ssl and shctx")

Thanks to Jeffrey J. Persch for reporting this bug.

Must be backported to 1.8.
---
 src/ssl_sock.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index f9d5f2567..322b05409 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -3849,8 +3849,12 @@ static int sh_ssl_sess_store(unsigned char *s_id, unsigned char *data, int data_
 		first->len = sizeof(struct sh_ssl_sess_hdr);
 	}
 
-	if (shctx_row_data_append(ssl_shctx, first, data, data_len) < 0)
+	if (shctx_row_data_append(ssl_shctx, first, data, data_len) < 0) {
+		shctx_row_dec_hot(ssl_shctx, first);
 		return 0;
+	}
+
+	shctx_row_dec_hot(ssl_shctx, first);
 
 	return 1;
 }
-- 
2.13.6

Re: Haproxy 1.8 version help

[Philipp Buehler]

Am 03.01.2018 17:39 schrieb Lukas Tribus:

To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
CentOs 6 only ships GCC 4.4.7, therefor compilation fails.


Waaah, thanks for telling before I tried to rush 1.8 to customer :-P

Rather not in the mood to make a build-VM with 4.7+ on C6 .. :-}
*hint*

ciao
--
pb

Re: HAProxy 1.8.3 SSL caching regression

[William Lallemand]

On Wed, Jan 03, 2018 at 12:04:50PM -0500, Jeffrey J. Persch wrote:
> Greetings,
> 

Hi Jeffrey,

> We have been load testing 1.8.3 and noticed SSL caching was broken in 1.8
> during the shctx refactoring.
> 
> New SSL connections will cache up until tune.ssl.cachesize, then no
> connections will ever be cached again.
> 
> In haproxy 1.7 and before, the SSL cache works correctly as a LRU cache.
> 
> 
> [...] 
> 
> This appears to independent of target & openssl version, we have reproduced
> on linux2628 openssl 1.0.1k-fips and osx openssl 1.0.2n.
> 
> Any insights appreciated.
> 

I'm able to reproduce the problem thanks to your detailed example, it looks
like a regression in the code.

I will check the code to see what's going on.

-- 
William Lallemand

HAProxy 1.8.3 SSL caching regression

[Jeffrey J. Persch]

Greetings,

We have been load testing 1.8.3 and noticed SSL caching was broken in 1.8
during the shctx refactoring.

New SSL connections will cache up until tune.ssl.cachesize, then no
connections will ever be cached again.

In haproxy 1.7 and before, the SSL cache works correctly as a LRU cache.


Example configuration file, haproxy-ssl-cache.cfg, with cachesize set to 3
to easily reproduce:

global
ssl-default-bind-ciphers HIGH:!aNULL:!MD5
ssl-default-bind-options no-sslv3 no-tls-tickets
tune.ssl.default-dh-param 2048
tune.ssl.cachesize 3
tune.ssl.lifetime 60

defaults
stats enable
stats uri /haproxy/stats

frontend some-frontend
bind :8443 ssl crt self-signed.pem
mode http
timeout client 15s
timeout http-request 15s
use_backend some-backend

backend some-backend
mode http
timeout connect 1s
timeout queue 0s
timeout server 1s
server some-server 127.0.0.1:8091 check


Example script to build and test on macosx:

srcdir=haproxy-1.8

# Install openssl library
brew install openssl

# Build HAProxy with OpenSSL support
make -C $srcdir TARGET=osx USE_OPENSSL=1
SSL_INC=/usr/local/opt/openssl/include
SSL_LIB=/usr/local/opt/openssl/lib USE_ZLIB=1

# Generate self signed cert
openssl req -newkey rsa:2048 -nodes -keyout self-signed.key -x509
-days 365 -out self-signed.crt -subj
"/C=US/ST=Pennsylvania/L=Philadelphia/O=HAProxy/OU=QA/CN=localhost"
cat self-signed.crt self-signed.key >>self-signed.pem

# Run HAProxy
$srcdir/haproxy -f haproxy-ssl-cache.cfg &

# Demonstrate failure to cache new sessions after cache fills
openssl s_client -connect localhost:8443 -reconnect -no_ticket
verify.err | egrep 'New|Reused' # PASS: 1 New, 5 Reused
openssl s_client -connect localhost:8443 -reconnect -no_ticket
verify.err | egrep 'New|Reused' # PASS: 1 New, 5 Reused
openssl s_client -connect localhost:8443 -reconnect -no_ticket
verify.err | egrep 'New|Reused' # PASS: 1 New, 5 Reused
openssl s_client -connect localhost:8443 -reconnect -no_ticket
verify.err | egrep 'New|Reused' # FAIL: 6 New

# Demonstrate failure to evict old entries from cache
sleep 65
openssl s_client -connect localhost:8443 -reconnect -no_ticket
verify.err | egrep 'New|Reused' # FAIL: 6 New


This appears to independent of target & openssl version, we have reproduced
on linux2628 openssl 1.0.1k-fips and osx openssl 1.0.2n.

Any insights appreciated.

Thanks,
Jeffrey J. Persch

Re: 1.8.3: Slow posts on H2 (IE only?)

[Willy Tarreau]

Hi Lukas,

On Wed, Jan 03, 2018 at 05:34:36PM +0100, Lukas Tribus wrote:
> Hello Peter,
> 
> 
> On Wed, Jan 3, 2018 at 2:59 PM, Lukas Tribus  wrote:
> > I will come back later and take a deeper look at both strace and the 
> > capture.
> 
> So, this is broken since c4134ba8b0 ("BUG/MEDIUM: h2: don't switch the
> state to HREM before end of DATA frame").
> And indeed Edge sets the ES bit in the last DATA frame of the POST issue.

They should all do that anyway since the ES bit marks the end of the stream.
But it's possible there's a small difference between implementations leading
to Edge triggering our bug easier.

> When moving the affected HREM code above the "return 0" branch, Edge
> works fine again.
> 
> The attached patch fixes the issue for me, please give it a try.

The problem with doing this is that when we have to stop transferring
data because for example the target buffer is full, we'll still switch
to HREM anyway and randomly destroy the last data frame. It was one of
the reasons some uploads were randomly truncated.

But if it fixes the issue for you, it may indicate we're not properly
woken up sometimes during the upload. If I understand well, it only
happens on redirects, so maybe one transition is causing trouble here,
typically we may have an HLOC state (half-close(local)) when the response
is sent by the server before the client finishes to upload, and it's
possible that we don't continue to drain pending data there. With
your change it likely causes the stream to be aborted on this last
frame, unblocking the situation. That's just a wild guess, as usual :-/

Willy

Re: Haproxy 1.8 version help

[Devendra Joshi]

HI Lukas,

Thanks for the help. will check and let you know.




Devendra Joshi
8080106035
--
--


On 3 January 2018 at 22:09, Lukas Tribus  wrote:

> Hello Devendra,
>
>
>
> On Wed, Jan 3, 2018 at 5:29 PM, Devendra Joshi
>  wrote:
> > Hi,
> >
> > I am using Haproxy 1.7-stable version and its working fine.
> > now i am upgrading to 1.8-stable, but i am getting error.
> >
> > do i need to update some package for this or can work with existing
> config.
> >
> > OS : CentOS 6.7
> >
> >
> > Note : I check Haproxy 1.8-stable on CentOS 7, its not showing any
> problem
> > during installation but in CentOS 6.7 showing following Error.
> >
> >
> >
> >
> >
> >
> > src/hathreads.o: In function `thread_want_sync':
> > /softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
> > `__atomic_or_fetch'
> > src/hathreads.o: In function `thread_exit_sync':
> > /softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
> > `__atomic_and_fetch'
> > src/hathreads.o: In function `thread_sync_barrier':
> > /softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
> > `__atomic_compare_exchange_n'
> > /softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
> > `__atomic_or_fetch'
> > src/lb_map.o: In function `recalc_server_map':
> > /softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
> > `__atomic_sub_fetch'
> > src/compression.o: In function `deinit_comp_ctx':
> > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > `__atomic_sub_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> > `__atomic_sub_fetch'
> > src/compression.o: In function `init_comp_ctx':
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> > `__atomic_add_fetch'
> > src/compression.o: In function `alloc_zlib':
> > /softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
> > `__atomic_add_fetch'
> > src/compression.o: In function `free_zlib':
> > /softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
> > `__atomic_sub_fetch'
> > src/time.o: In function `tv_update_date':
> > /softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
> > `__atomic_compare_exchange_n'
> > collect2: ld returned 1 exit status
> > make: *** [haproxy] Error 1
>
>
> To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
> CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
> You can disable thread support, by adding USE_THREAD= to the make
> command (nothing comes after the equal sign):
>
> make clean; make TARGET=linux2628 USE_OPENSSL=1 [...] USE_THREAD=
>
>
> Regards,
> Lukas
>

Re: Haproxy 1.8 version help

[Lukas Tribus]

Hello Devendra,



On Wed, Jan 3, 2018 at 5:29 PM, Devendra Joshi
 wrote:
> Hi,
>
> I am using Haproxy 1.7-stable version and its working fine.
> now i am upgrading to 1.8-stable, but i am getting error.
>
> do i need to update some package for this or can work with existing config.
>
> OS : CentOS 6.7
>
>
> Note : I check Haproxy 1.8-stable on CentOS 7, its not showing any problem
> during installation but in CentOS 6.7 showing following Error.
>
>
>
>
>
>
> src/hathreads.o: In function `thread_want_sync':
> /softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
> `__atomic_or_fetch'
> src/hathreads.o: In function `thread_exit_sync':
> /softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
> `__atomic_and_fetch'
> src/hathreads.o: In function `thread_sync_barrier':
> /softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
> `__atomic_compare_exchange_n'
> /softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
> `__atomic_or_fetch'
> src/lb_map.o: In function `recalc_server_map':
> /softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
> `__atomic_add_fetch'
> /softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
> `__atomic_sub_fetch'
> src/compression.o: In function `deinit_comp_ctx':
> /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> `__atomic_sub_fetch'
> /softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
> `__atomic_sub_fetch'
> src/compression.o: In function `init_comp_ctx':
> /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> `__atomic_add_fetch'
> /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> `__atomic_add_fetch'
> /softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
> `__atomic_add_fetch'
> src/compression.o: In function `alloc_zlib':
> /softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
> `__atomic_add_fetch'
> src/compression.o: In function `free_zlib':
> /softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
> `__atomic_sub_fetch'
> src/time.o: In function `tv_update_date':
> /softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
> `__atomic_compare_exchange_n'
> collect2: ld returned 1 exit status
> make: *** [haproxy] Error 1


To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
You can disable thread support, by adding USE_THREAD= to the make
command (nothing comes after the equal sign):

make clean; make TARGET=linux2628 USE_OPENSSL=1 [...] USE_THREAD=


Regards,
Lukas

Re: 1.8.3: Slow posts on H2 (IE only?)

[Lukas Tribus]

Hello Peter,


On Wed, Jan 3, 2018 at 2:59 PM, Lukas Tribus  wrote:
> I will come back later and take a deeper look at both strace and the capture.

So, this is broken since c4134ba8b0 ("BUG/MEDIUM: h2: don't switch the
state to HREM before end of DATA frame").
And indeed Edge sets the ES bit in the last DATA frame of the POST issue.

When moving the affected HREM code above the "return 0" branch, Edge
works fine again.


The attached patch fixes the issue for me, please give it a try.


cheers,
lukas
diff --git a/src/mux_h2.c b/src/mux_h2.c
index c6e15ec..c3fc64e 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -1693,19 +1693,18 @@ static int h2c_frt_handle_data(struct h2c *h2c, struct 
h2s *h2s)
h2c->st0 = H2_CS_FRAME_E;
}
 
-   /* check for completion : the callee will change this to FRAME_A or
-* FRAME_H once done.
-*/
-   if (h2c->st0 == H2_CS_FRAME_P)
-   return 0;
-
-
/* last frame */
if (h2c->dff & H2_F_DATA_END_STREAM) {
h2s->st = H2_SS_HREM;
h2s->flags |= H2_SF_ES_RCVD;
}
 
+   /* check for completion : the callee will change this to FRAME_A or
+* FRAME_H once done.
+*/
+   if (h2c->st0 == H2_CS_FRAME_P)
+   return 0;
+
return 1;
 
  conn_err:

Fwd: Haproxy 1.8 version help

[Devendra Joshi]

Hi,

I am using Haproxy 1.7-stable version and its working fine.
now i am upgrading to 1.8-stable, but i am getting error.

do i need to update some package for this or can work with existing config.

OS : CentOS 6.7


Note : I check Haproxy 1.8-stable on CentOS 7, its not showing any problem
during installation but in CentOS 6.7 showing following Error.






src/hathreads.o: In function `thread_want_sync':
/softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
`__atomic_or_fetch'
src/hathreads.o: In function `thread_exit_sync':
/softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
`__atomic_and_fetch'
src/hathreads.o: In function `thread_sync_barrier':
/softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
`__atomic_compare_exchange_n'
/softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
`__atomic_or_fetch'
src/lb_map.o: In function `recalc_server_map':
/softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
`__atomic_sub_fetch'
src/compression.o: In function `deinit_comp_ctx':
/softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
`__atomic_sub_fetch'
/softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
`__atomic_sub_fetch'
src/compression.o: In function `init_comp_ctx':
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
src/compression.o: In function `alloc_zlib':
/softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
`__atomic_add_fetch'
src/compression.o: In function `free_zlib':
/softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
`__atomic_sub_fetch'
src/time.o: In function `tv_update_date':
/softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
`__atomic_compare_exchange_n'
collect2: ld returned 1 exit status
make: *** [haproxy] Error 1






Devendra Joshi
8080106035
--
--


-- Forwarded message --
From: Devendra Joshi 
Date: 3 January 2018 at 16:57
Subject: Haproxy 1.8 version help
To: devendra joshi 


Hi,

I am using Haproxy 1.7-stable version and its working fine.
now i am upgrading to 1.8-stable, but i am getting error.

do i need to update some package for this or can work with existing config.

OS : CentOS 6.7


Note : I check Haproxy 1.8-stable on CentOS 7, its not showing any problem
during installation but in CentOS 6.7 showing following Error.






src/hathreads.o: In function `thread_want_sync':
/softwares/haproxy-1.8.2/src/hathreads.c:75: undefined reference to
`__atomic_or_fetch'
src/hathreads.o: In function `thread_exit_sync':
/softwares/haproxy-1.8.2/src/hathreads.c:142: undefined reference to
`__atomic_and_fetch'
src/hathreads.o: In function `thread_sync_barrier':
/softwares/haproxy-1.8.2/src/hathreads.c:108: undefined reference to
`__atomic_compare_exchange_n'
/softwares/haproxy-1.8.2/src/hathreads.c:109: undefined reference to
`__atomic_or_fetch'
src/lb_map.o: In function `recalc_server_map':
/softwares/haproxy-1.8.2/src/lb_map.c:116: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/lb_map.c:125: undefined reference to
`__atomic_sub_fetch'
src/compression.o: In function `deinit_comp_ctx':
/softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
`__atomic_sub_fetch'
/softwares/haproxy-1.8.2/src/compression.c:199: undefined reference to
`__atomic_sub_fetch'
src/compression.o: In function `init_comp_ctx':
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
/softwares/haproxy-1.8.2/src/compression.c:177: undefined reference to
`__atomic_add_fetch'
src/compression.o: In function `alloc_zlib':
/softwares/haproxy-1.8.2/src/compression.c:469: undefined reference to
`__atomic_add_fetch'
src/compression.o: In function `free_zlib':
/softwares/haproxy-1.8.2/src/compression.c:500: undefined reference to
`__atomic_sub_fetch'
src/time.o: In function `tv_update_date':
/softwares/haproxy-1.8.2/src/time.c:228: undefined reference to
`__atomic_compare_exchange_n'
collect2: ld returned 1 exit status
make: *** [haproxy] Error 1









Devendra Joshi

--
--
[root@web haproxy-1.8.2]# make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 
USE_ZLIB=1
gcc  -g -o haproxy src/ev_poll.o src/ev_epoll.o src/ssl_sock.o ebtree/ebtree.o 
ebtree/eb32sctree.o ebtree/eb32tree.o 

Re: 1.8.3: Slow posts on H2 (IE only?)

[Lukas Tribus]

Hello Peter,


On Wed, Jan 3, 2018 at 12:00 PM, Peter Lindegaard Hansen
 wrote:
>
> Hi List,
>
> We updated one of our haproxy boxes to the newly released 1.8.3 - thanks!
>
> Then we got reports of IE being slow, when we looked into the claims we found 
> that it seems to related to POSTs that respond in a header location redirect.
>
> We can reproduce the slowness with a ultra simple php script like this:

Thanks, I can reproduce it.

I don't see the CONNECT you are saying, but the behavior is as broken
as it is on your end here. The problem is not the redirect itself, but
the GET request after the 302 redirect.
I was able to downgrade TLS to non-FS ciphers (Edge does not reject it
in H2 as would be required by the specs), so I was able to decrypt it.
Haproxy does not respond to the (post 302 redirect) GET request at all
(it doesn't even show up in the debug log).

Attaching capture, private SSL key (invalid certificate) and strace output.


I did not go through the strace output yet and I couldn't find
anything wrong with the browsers request in the capture. I'm posting
this data now here. I will come back later and take a deeper look at
both strace and the capture.


The private key needs to be configured for 10.0.0.33 port 443 protocol
http in Wireshark (Preferences/Protocols/SSL/RSA Keys), for the
session to be decrypted.




cheers,
lukas
lukas@dev:~/haproxy$ sudo strace -tt ./haproxy -f ../haproxy.cfg -d
14:36:22.959623 execve("./haproxy", ["./haproxy", "-f", "../haproxy.cfg", 
"-d"], [/* 15 vars */]) = 0
14:36:22.960767 brk(NULL)   = 0x2981000
14:36:22.961097 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.961349 mmap(NULL, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce5ee24000
14:36:22.961598 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.961911 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
14:36:22.962149 fstat(3, {st_mode=S_IFREG|0644, st_size=24208, ...}) = 0
14:36:22.962427 mmap(NULL, 24208, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce5ee1e000
14:36:22.962642 close(3)= 0
14:36:22.962920 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.963137 open("/lib/x86_64-linux-gnu/libcrypt.so.1", O_RDONLY|O_CLOEXEC) 
= 3
14:36:22.963340 read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\v\0\0\0\0\0\0"..., 832) = 832
14:36:22.963623 fstat(3, {st_mode=S_IFREG|0644, st_size=39224, ...}) = 0
14:36:22.963839 mmap(NULL, 2322912, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce5e9c9000
14:36:22.964050 mprotect(0x7fce5e9d2000, 2093056, PROT_NONE) = 0
14:36:22.964273 mmap(0x7fce5ebd1000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7fce5ebd1000
14:36:22.964543 mmap(0x7fce5ebd3000, 184800, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce5ebd3000
14:36:22.964764 close(3)= 0
14:36:22.964993 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.965211 open("/lib/x86_64-linux-gnu/libpthread.so.0", 
O_RDONLY|O_CLOEXEC) = 3
14:36:22.965449 read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260`\0\0\0\0\0\0"..., 832) = 832
14:36:22.965647 fstat(3, {st_mode=S_IFREG|0755, st_size=138696, ...}) = 0
14:36:22.965937 mmap(NULL, 2212904, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce5e7ac000
14:36:22.966147 mprotect(0x7fce5e7c4000, 2093056, PROT_NONE) = 0
14:36:22.966355 mmap(0x7fce5e9c3000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fce5e9c3000
14:36:22.966609 mmap(0x7fce5e9c5000, 13352, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce5e9c5000
14:36:22.966827 close(3)= 0
14:36:22.967136 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.967388 open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
14:36:22.967686 read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\r\0\0\0\0\0\0"..., 832) = 
832
14:36:22.967901 fstat(3, {st_mode=S_IFREG|0644, st_size=14608, ...}) = 0
14:36:22.968135 mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce5ee1d000
14:36:22.968346 mmap(NULL, 2109680, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce5e5a8000
14:36:22.968549 mprotect(0x7fce5e5ab000, 2093056, PROT_NONE) = 0
14:36:22.968732 mmap(0x7fce5e7aa000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fce5e7aa000
14:36:22.968953 close(3)= 0
14:36:22.969189 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:36:22.969403 open("/usr/lib/x86_64-linux-gnu/liblua5.3.so.0", 
O_RDONLY|O_CLOEXEC) = 3
14:36:22.969627 read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0pi\0\0\0\0\0\0"..., 832) = 832
14:36:22.969867 fstat(3, {st_mode=S_IFREG|0644, st_size=224104, ...}) = 0

Re[2]: Poll: haproxy 1.4 support ?

[Aleksandar Lazic]

-- Originalnachricht --
Von: "Marco Corte" 
An: haproxy@formilux.org
Gesendet: 03.01.2018 13:20:31
Betreff: Re: Poll: haproxy 1.4 support ?


Hello.

My vote to drop support for version 1.4

+1



.marcoc


regards
Aleks

Re: Poll: haproxy 1.4 support ?

[Marco Corte]

Hello.

My vote to drop support for version 1.4

.marcoc

Re: AW: Poll: haproxy 1.4 support ?

[Lukas Tribus]

Hello,


On Wed, Jan 3, 2018 at 9:02 AM, Pavlos Parissis
 wrote:
> On 03/01/2018 08:50 πμ, Maximilian Böhm wrote:
>> Debian (Jessie) distributes Haproxy 1.5.8.3
>>
>
> Well, Debian users can also use https://haproxy.debian.net/ to get any 
> version they want.
> For more details, please read
> https://packages.debian.org/search?suite=jessie-backports=names=haproxy


Sure, it's just that a lot of people out there are still running 1.5,
whether there is the possibility to upgrade or not. I would not drop
1.5 completely from our radar, but set it to something like "Critical
fixes only".

I agree to drop 1.4 support completely.


Regards,
Lukas

Re: AW: Poll: haproxy 1.4 support ?

[Pavlos Parissis]

On 03/01/2018 08:50 πμ, Maximilian Böhm wrote:
> Debian (Jessie) distributes Haproxy 1.5.8.3
> 

Well, Debian users can also use https://haproxy.debian.net/ to get any version 
they want.
For more details, please read
https://packages.debian.org/search?suite=jessie-backports=names=haproxy

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature