Re: Configure HAProxy to Bridge H2 or HTTPS/1.1 to HTTPS/1.1

Hello Maximilian, Am 20.11.2016 um 21:13 schrieb Maximilian Böhm: Hi there, I currently explore the possibilities of HAProxy. This thing can do a lot :) Now I’ve reached a point where I do not know what to do next. I’ve compiled HAProxy from sources with version 1.7-dev6 (See -vv below).

Re: Routing traffic using req_ssl_sni failing

Hello Oliver, Am 21.11.2016 um 17:43 schrieb Wood, Oliver: Hello, I’ve what feels like a very simple problem, but that I cannot get to work. I’ve two backends, and I wish to route HTTPS traffic to them based on the original source request, without SSL offloading. I ran across

Re: http/1.1, h2, HSTS, nginx, proxy_protocol: Seeking some advice and help

No way this will work, as Haproxy doesn't support HTTP2 and when you use Chrome, HTTP2 is what will be negotiated. You will have to add this header in nginx. Lukas

Re: problem building haproxy 1.6.9 on ar71xx

Hi Thomas, Am 10.11.2016 um 22:20 schrieb Thomas Heil: Also see: https://www.openssl.org/docs/man1.1.0/crypto/ERR_remove_state.html hmm. did i read correctly, that this function does nothing? It does nothing in openssl 1.1.0, as it isn't required in that branch. However it is required

Re: problem building haproxy 1.6.9 on ar71xx

Hi, Am 10.11.2016 um 18:27 schrieb Thomas Heil: Hi, Iam facing a problem when building haproxy 1.6.9 with ssl for mips_24kc with musl 1.1.15. Openssl was building fine, but the function "ERR_remove_state(0)" does not exist but ERR_remove_thread_state(0); is available. So does anybody know

Re: Haproxy 1.6.9 failed to compile regex

Hello, Am 28.10.2016 um 01:03 schrieb Willy Tarreau: For the record: this has been fixed; and I also implemented the correct "Built with PCRE" information. Haproxy 1.6.10 will contain those fixes. ~/haproxy-1.6$ git log --oneline v1.6.9.. | grep PCRE dcdd2ae MINOR: show Built with PCRE

Re: Haproxy 1.6.9 failed to compile regex

Hello, Am 08.09.2016 um 17:48 schrieb Lukas Tribus: Means that haproxy -vv reported "Built with PCRE version" version wrong previously. That confused me. This returns the output of pcre_version() and yes, the text should be renamed to "Running with PCRE version",

Re: [PR] Cleanup

Hello, Am 26.10.2016 um 15:06 schrieb PR Bot No-Reply: Dear list! Author: Erwan Velu Number of patches: 8 This is an automated relay of the Github pull request: Cleanup Patch title(s): CLEANUP: don't ignore debian/ directory if present cfgparse: Protect

[PR] Added dist tag to to release field in .spec file

Dear list! Author: Sasa Tekovic Number of patches: 1 This is an automated relay of the Github pull request: Added dist tag to to release field in .spec file Patch title(s): Added dist tag to to release field in .spec file Link:

Github PR: Fix typo in description of `-st` parameter

Dear list! This is an automated relay of the Github pull request: Fix typo in description of `-st` parameter Author: Jorrit Schippers Number of patches: 1 Patch titles: Fix typo in description of `-st` parameter Link: https://github.com/haproxy/haproxy/pull/65 Edit locally:

Re: HAProxy reloads lets old and outdated processes

Hello, Am 24.10.2016 um 22:32 schrieb Pavlos Parissis: IMHO: Ask the users to not perform reloads every 2miliseconds. It is insane. You may spend X hours on this which will make the code a bot more complex and cause possible breakages somewhere else. Not fixing *real world issues* because

Re: CVE-2016-2183 vulnerability

Hi Ed, Am 20.10.2016 um 18:01 schrieb Ed Guizar: We are running HAProxy version 1.5.14. Our external PCI can failed due to CVE-2016-2183 vulnerability. Apparently we need to disable DES and 3DES, at least that is what I understand from reading the description. How can I accomplish this?

Re: HAProxy reloads lets old and outdated processes

Hi Pierre, Am 13.10.2016 um 18:56 schrieb Pierre Cheynier: This becomes impossible in PaaS-like approach where many events occurs and may trigger reloads every seconds. BTW, the new "no-reuseport" feature does not help in my case (as well as ip/nftables or tc workarounds) because it

Re: mode tcp and http type acls and keepalive

Hi David, Am 28.09.2016 um 00:40 schrieb David Birdsong: I managed to disable keepalive properly and now I see the problem completely resolve itself. Is there some way to use mixed-content frontends w/ a previously opened connection and still detect HTTP (the default HTTP acl)? Provide

Re: [DEV] ssl bind_conf per certificat

Hi Manu, Am 23.09.2016 um 16:31 schrieb Emmanuel Hocdet: Hi all, I propose to discuss an option to declare ssl options per certificat/SNI (instead of global one on bind directive). use cases will be to set alpn/verify/ per SNI. I think this would be useful and could simplify some

Re: How to control traffic like linux TC, instead of reject it?

Hello JWD, all your emails are arriving, there is no need to double or triple post your questions. Please stop doing that. When you say "control traffic like linux TC", do you mean traffic shaping? Haproxy doesn't support traffic shaping as far as I know. Lukas

Re: [PATCH] MINOR: enable IP_BIND_ADDRESS_NO_PORT on backend connections

Am 14.09.2016 um 18:26 schrieb Lukas Tribus: would not benefit from this feature. This should have been "it is not even necessary" instead of "no benefit". Lukas

Re: [PATCH] MINOR: enable IP_BIND_ADDRESS_NO_PORT on backend connections

Hi Pavlos, Am 14.09.2016 um 16:01 schrieb Pavlos Parissis: The commit on Linux kernel mentions: """ The port will be automatically chosen at connect() time, in a way that allows sharing a source port as long as the 4-tuples are unique. """ confused me a bit as it says that the same source

[PATCH] MINOR: enable IP_BIND_ADDRESS_NO_PORT on backend connections

Enable IP_BIND_ADDRESS_NO_PORT on backend connections when the source address is specified without port or port ranges. This is supported since Linux 4.2/libc 2.23. If the kernel supports it but the libc doesn't, we can define it at build time: make [...] DEFINE=-DIP_BIND_ADDRESS_NO_PORT=24 For

[PATCH 4/4] MEDIUM: make SO_REUSEPORT configurable

With Linux officially introducing SO_REUSEPORT support in 3.9 and its mainstream adoption we have seen more people running into strange SO_REUSEPORT related issues (a process management issue turning into hard to diagnose problems because the kernel load-balances between the new and an obsolete

[PATCH 1/4] BUG/MINOR: displayed PCRE version is running release

pcre_version() returns the running PCRE release, not the release haproxy was built with. This simple string fix should be backported to supported releases, as the output may be confusing. --- src/haproxy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/haproxy.c

[PATCH 3/4] MINOR: show Running on zlib version

--- src/haproxy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/haproxy.c b/src/haproxy.c index 6d0681c..96ecd0d 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@ -292,6 +292,7 @@ void display_build_opts() #ifdef USE_ZLIB printf("Built with zlib version : " ZLIB_VERSION

[PATCH 2/4 v2] MINOR: show Built with PCRE version

Inspired by PCRE's pcre_version.c and improved with Willy's suggestions. Reusable parts have been added to include/common/standard.h. --- include/common/standard.h | 9 + src/haproxy.c | 3 +++ 2 files changed, 12 insertions(+) diff --git a/include/common/standard.h

Re: [PATCH 2/3] MINOR: show Built with PCRE version

Hi Willy, Am 12.09.2016 um 21:40 schrieb Willy Tarreau: > > Could we please have something supporting commas instead ? > > The version above breaks on formats like this : > >ptr = XSTRING(PCRE_MAJOR,PCRE_MINOR) STRING(,) XSTRING(PCRE_MINOR); > > This one is more robust and works : > >

[PATCH 3/3] MINOR: show Running on zlib version

--- No strong opinion about whether it makes sense to backport this. --- src/haproxy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/haproxy.c b/src/haproxy.c index 5d6874f..28ea525 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@ -292,6 +292,7 @@ void display_build_opts() #ifdef

[PATCH 2/3] MINOR: show Built with PCRE version

Inspired by PCRE's pcre_version.c, reusable parts have been added to include/common/standard.h. --- No strong opinion about whether it makes sense to backport this. --- include/common/standard.h | 7 +++ src/haproxy.c | 3 +++ 2 files changed, 10 insertions(+) diff --git

[PATCH 1/3] BUG/MINOR: displayed PCRE version is running release

pcre_version() returns the running PCRE release, not the release haproxy was built with. This simple string fix should be backported to supported releases, as the output may be confusing. --- Seen in mailing list thread: "Haproxy 1.6.9 failed to compile regex" --- src/haproxy.c | 2 +- 1 file

Re: Issue with configuration reload and frontend certificates

Ciao Marco, I assume the old process did not get the signal and continues to serve requests with the old configuration. Can you confirm the number of haproxy processes running is more than you expect? Are you using nbproc or single process mode (the latter is the default)? Does the PID

Re: Haproxy 1.6.9 failed to compile regex

Hello Veiko, Am 08.09.2016 um 13:11 schrieb Veiko Kukk: Yes, turned out, build box had newer pcre installed (7 vs 8 major version). Compiling pcre statically solved that error/problem. Good to hear. If you link against a shared library, you will have to make sure they match in major

Re: Haproxy 1.6.9 failed to compile regex

Am 07.09.2016 um 16:42 schrieb Veiko Kukk: On 07/09/16 14:37, Veiko Kukk wrote: I tried to upgrade from 1.6.8 to 1.6.9, but found strange errors printed by haproxy 1.6.9. Any ideas, why? Another strange issue is that 1.6.9 shows: Running on OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010

Re: haproxy does not correctly handle MSS on Freebsd

Hi Simon, Packets's segment should be 16344 as the advertised value. Wrong. The negotiated value is a maximum (the M in MSS means maximum), not a guaranteed value. There is nothing wrong with TCP segments below the MSS. Whether the stack is segmenting at MSS size depends on a lot of

Re: haproxy does not correctly handle MSS on Freebsd

Hi Simon, Am 19.08.2016 um 12:41 schrieb k simon: Hi,List: Haproxy's throughput is much less than nginx or squid on FreeBSD and it's high cpu usage often. When I investigate it a bit more, I found haproxy does not correctly handle MSS on FreeBSD. Your kernel decides the segment size of

Re: Cisco GSS keepalive and haproxy not working

Hi Jay, Am 18.08.2016 um 14:54 schrieb Jay Modha: I have been analysing the tcpdump a between 1.4 and 1.5. The main difference I see on the response that haproxy send back to the GSS is the TCP Segment Length. In 1.4 the TCP Segment Length is 0. In 1.5 the TCP Segment Length is 477. Is

Re: Cisco GSS keepalive and haproxy not working

Hi Jay, Am 16.08.2016 um 17:20 schrieb Jay Modha: We are in the process of upgrading to 1.5.x however when we deploy our app using 1.5.8 the GSS keepalive no longer detects any nodes as being alive and ultimately results in DNS error when some tries to access the application via the DNS.

Re: question about http request rate limit

Hello, yes the errorfile configuration is what I mean, the error you need to catch being 503 (timeout queue). Regards, Lukas

Re: SEGV with sc_trackers

Here's a stacktrace on Linux without compiler optimizations: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x080f504b in smp_fetch_sc_trackers (args=0x9b86de0, smp=0xbfffdfd4, kw=0x81317c7 "sc0_trackers", private=0x0) at src/stream.c:3265 3265smp->data.u.sint =

Re: question about http request rate limit

Hello, Am 12.08.2016 um 17:01 schrieb Artem Lalaiants: Hello, I'm trying to limit traffic based on the amount of http requests load balancer handles at the moment. The way to do this is to use maxconn on the various parts of haproxy (backend, frontend, servers etc). This also includes a

Re: haproxy terminate with ssl backend

Hi Daniel, Am 11.08.2016 um 09:07 schrieb daniel sanders: Hi all I need to know if i can terminate SSL on a fronded with SNI and then create a new ssl session to the backend Yes, it is possible. All you need is to specify the ssl keyword on the server configuration in the backend section.

Re: SYN dropping at reload time

Am 09.08.2016 um 16:39 schrieb Aleksandar Lazic: On Linux yes, because there is a race condition: http://lwn.net/Articles/542866/ http://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html Thanks. So every Software on Linux should have this issue right? I'm one of

Re: SYN dropping at reload time

Hi Aleksandar, Am 09.08.2016 um 13:42 schrieb Aleksandar Lazic: I know it's not the latest one ;-/. Is there really a possibility that at soft-reload incoming request are failed? On Linux yes, because there is a race condition: http://lwn.net/Articles/542866/

Re: Haproxy if acl problem

Hi Andrzej, Am 08.08.2016 um 10:02 schrieb Andrzej Sobociński: Hello. I have issue with haproxy 1.6 (meaby that is bug) My config in backend section: acl acl_address_xxx hdr(host) -i xxx.domain.com http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains;

Re: Inform backend about https for http2 connections

Hi, Am 07.08.2016 um 13:35 schrieb Matthias Fechner: I think the only possibilty whould then to define several backends on different ports and define there the h2c or h2 in the frontend configuration of nginx. Yes, because otherwise you have a problem on the nginx configuration as well:

Re: Haproxy 1.6.7 segmentation fault under load

Hi James, Am 02.08.2016 um 19:09 schrieb James Hartshorn: (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 #1 0x00498717 in fill_window () #2 0x00498c20 in deflate_fast () #3 0x0049a2e3 in deflate () #4

Re: HAProxy fails to start with ³invalid address² when using IPv6 Resolvable Name in the Backend

I answered you on discourse, but please refrain from cross-posting: http://discourse.haproxy.org/t/haproxy-fails-to-start-with-invalid-address-when-using-ipv6-resolvable-name-in-the-backend/526/2?u=lukastribus Thanks, Lukas

Re: Problems with SNI + TLS passthrough

Am 09.07.2016 um 00:18 schrieb Ben Whaley: Thanks, Lukas, this makes sense. I misunderstood that because SNI is not part of the HTTP session, perhaps it could still be adjusted with TCP mode. Ultimately I need to do two-way SSL between the client and the service, and for that I need both of

Re: Problems with SNI + TLS passthrough

Hi Ben, Am 08.07.2016 um 18:51 schrieb Ben Whaley: Greetings, I have a scenario like this: Client <=> HAP1 <=> HAP2 <=> Java service Both HAPs in this config use TCP mode for TLS passthrough with SNI for routing decisions, as described in this helpful post:

Re: haproxy's resolver send queries with "response" flag

Hi, Am 17.06.2016 um 20:56 schrieb Cyril Bonté: This has been fixed after 1.6.5 with commit 5f60de0866 "BUG/MEDIUM: dns: unbreak DNS resolver after header fix". http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=5f60de08667c3472d95cc20b87753e9fd8520057 Willy, maybe we should release

Re: HTTP Keep Alive : Limit number of sessions in a connection

Hi, Am 16.06.2016 um 14:03 schrieb Pavlos Parissis: HAProxy has this one2one relationship between client and backend server connection, where a connection established between haproxy and the backend server belongs to the client that initiated it. When the client is a bot or a program which

Re: Setting OCSP response via socket

Hello, Am 14.06.2016 um 18:31 schrieb Thijs Kinkhorst: If so, I'd like it to become possible, because I'd prefer to be able to set this entirely via the socket approach, and not having to special case the initial condition where the response was not present. But then you will have a race

Re: HTTP Keep Alive : Limit number of sessions in a connection

Hi, Am 08.06.2016 um 20:51 schrieb CJ Ess: I'm terminating connections with nginx, then I have a pool of upstream connections from nginx to haproxy where I allow unlimited keep-alive requests between nginx and haproxy per connection. The only times the connections close is when haproxy sends

Re: HTTP Keep Alive : Limit number of sessions in a connection

Am 07.06.2016 um 21:32 schrieb Manas Gupta: Hi Lukas, My understanding was that soft-stop will cater to new connections. That would mean soft stopping doesn't have any effect at all, basically. No, that's not the case, but either way your hardware load balancer would've already stopped

Re: HTTP Keep Alive : Limit number of sessions in a connection

Am 07.06.2016 um 20:31 schrieb Manas Gupta: Hi, We are running HAProxy (HTTP mode) behind a hardware load balancer operating at TCP (L3 layer). Clients go to the TCP loadbalancer which forwards the traffic to 1 of the many HAProxy servers. The L3 load balancer only comes into play at new TCP

Re: tcpdump and Haproxy SSL Offloading

Hi, Am 05.06.2016 um 02:19 schrieb Igor Cicimov: > In haproxy.cfg I used these cipher I found recommended: > ciphers ECDHE-RSA-AES256-SHA:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM I would not recommend this. Check [1] and [2] for some uptodate recommendations. Yes, removing

Re: tcpdump and Haproxy SSL Offloading

Hi, Am 04.06.2016 um 02:14 schrieb Igor Cicimov: you can dump the symmetric keys from the browser and import them in wireshark to decrypt PFS protected TLS sessions [1] Yes in case you want to troubleshoot something generic this is a good approach but if you want to troubleshoot

Re: Haproxy limiting queue / connections

There is really no need to set ulimit-n manually, haproxy will do that for you (as per the docs "it is recommended not to use this option"). Also, configuring maxconn correctly is the single most important configuration in haproxy, and will affect the performance as well as cause crashes if

Re: tcpdump and Haproxy SSL Offloading

Hello, you can dump the symmetric keys from the browser and import them in wireshark to decrypt PFS protected TLS sessions [1] or downgrade your ciphers settings to non-PF ciphers. Properly decrypting the TLS session is the only way to really make sure you see what happens, even if there is

Re: Haproxy limiting queue / connections

Hi Ari, If the backend servers are responding slowly for some reason, all haproxy nodes will crash. i configured queue to 1 and set up reasonable server and client timeouts on haproxy however if for some reason connections builds up on haproxy crashes and the machine becomes

[PATCH] BUG/MEDIUM: dns: unbreak DNS resolver after header fix

DNS requests (using the internal resolver) are corrupted since commit e2f84977165a ("BUG/MINOR: dns: fix DNS header definition"). Fix it by defining the struct in network byte order, while complying with RFC 2535, section 6.1. First reported by Eduard Vopicka on discourse. This must be

Re: 100% cpu , epoll_wait()

Hi Willy, Am 13.05.2016 um 17:01 schrieb Willy Tarreau: Hi Sebastian, On Thu, May 12, 2016 at 09:58:22AM +0200, Sebastian Heid wrote: Hi Lukas, starting from around 200mbit/s in, haproxy processes (nbproc 6) are hitting 100% cpu regularly (noticed up to 3 processes at the same time with

Re: Haproxy running on 100% CPU and slow downloads

Hi, Am 12.05.2016 um 14:37 schrieb Sachin Shetty: Hi Willy, We are seeing a strange problem on the patched server. We have several haproxy servers running but only one with the latest patch, and this haproxy has frozen twice in last two days, basically it hits max open connections 2000 on

Re: Crash with kernel error

ave to adjust limits for that user? Thank you for all your help, On Wed, May 11, 2016 at 4:02 PM, Lukas Tribus <lu...@gmx.net <mailto:lu...@gmx.net>> wrote: Hi Sasha, so the crash happens sporadically after hours of production traffic? Or does it crash right away after yo

Re: Crash with kernel error

Hi Sasha, so the crash happens sporadically after hours of production traffic? Or does it crash right away after you start it? You are saying this started with 1.6.4, what was the version you used before and that worked fine? 1.6.3? Before starting haproxy, enable core dumping like

Re: 100% cpu , epoll_wait()

Hi Sebastian, Am 11.05.2016 um 16:07 schrieb Sebastian Heid: Hi, I updated from 1.5.17 to 1.5.18 today, but sadly this issue still exits in the latest version in our environment. However downgrading to 1.5.14 "fixed" the issue for us. Seems like a different issue then. Can you elaborate

Re: [PATCH 1/4] BUG/MEDIUM: stats: show servers state may show an empty or incomplete result

Hi Willy, Am 06.05.2016 um 12:29 schrieb Willy Tarreau: Nice catch and good job. Just merged into 1.7 and will backport asap. I intend to emit a few releases this week-end as we have many bug fixes pending. Great. Just a quick reminder though, the following patch on the ML has yet to be

Re: redirect rule with multiple conditions

Hi Haim, Am 05.05.2016 um 21:24 schrieb Haim Ari: Hello, I'm trying to set a redirect rule with multiple conditions: Redirect any request unless from ip or path begin with… Please show your complete configuration including the default and global section and an output of haproxy -vv.

Re: sni lookup precedence order - delay default cert insertion

Hi, Am 05.05.2016 um 20:13 schrieb Roberto Guimaraes: First we have a fundamental disagreement in that you are saying haproxy does not implement a fallback cert: it may not explicitly implement one, but the default cert, the first specified cert becomes the fallback cert. fallback cert: if

Re: sni lookup precedence order - delay default cert insertion

Hi, Am 04.05.2016 um 01:46 schrieb Roberto Guimaraes: * couldn't access the page for a couple of days. crt-list did not help too much because we use dirs and it forces us to be explicit (unless I used it wrong - entirely possible) , which we try to avoid. It also follows the same problematic

Re: HTTPS with SSL pass-through

Hi Ondrej, your backend probably redirects indefinitely. I suggest you troubleshoot what happens exactly with curl (curl -vk https://example.com), that way you should be able to understand how the backend behaves. Regards, Lukas

Re: Erroneous error code on wrong configuration.

Hi, Am 01.05.2016 um 18:18 schrieb Jonathan Matthews: > frontend my_frontend > bind :80 > acl global hdr(host) -i blablabla > use_backend my_backend if global > backend my_backend > server google www.google.com:80 Given that you don't alter the Host

Re: sni lookup precedence order - delay default cert insertion

Hi Roberto, Am 27.04.2016 um 20:21 schrieb Roberto Guimaraes: Hi Lukas, thanks for the reply and apologize for not being as thorough in my original post. Tend to focus on the solution, rather than the problem it addresses... should have spent more time describing the problem. A short

Re: sni lookup precedence order - delay default cert insertion

Hi Roberto, I'm not quite sure what you are describing: Am 26.04.2016 um 20:24 schrieb Roberto Guimaraes: Hi, Not sure if valid, and even if so, it might be minor and related to specific use cases. So, I've noticed that if in the same bind line we have a fallback cert followed by more

Re: Issue setting limits from Systemd to Haproxy service

Hi Ricardo, haproxy sets those values itself. If you want custom settings, adjust the configuration (although its not recommended, because this is automatically computed based on maxconn configuration): http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#3.1-ulimit-n Also see:

Re: Haproxy running on 100% CPU and slow downloads

Hi Sachin, there is another fix Willy recently committed, its ff9c7e24fb [1] and its in the snapshots [2] since 1.6.4-20160426. This is supposed to fix the issue altogether. Please let us know if this works for you. Thanks, Lukas [1]

Re: Support for Keep-Alive header and timeouts

Am 25.04.2016 um 18:10 schrieb Craig McLure: >From a firewall perspective all sockets are configured to forcefully stop after about 20 minutes after which time a connection will go 'stale' and no longer function, any additional packets on that socket will be ignored. And why would you

Re: Support for Keep-Alive header and timeouts

Hi, Am 25.04.2016 um 15:51 schrieb Craig McLure: >From a firewall perspective all sockets are configured to forcefully stop after about 20 minutes after which time a connection will go 'stale' and no longer function, any additional packets on that socket will be ignored. And why would you

Re: haproxy 1.6.4 segfault in logging (I think)

Hi David, thanks, that's extremely useful. Seems like we access memory that we are not supposed to access. I bisected this to eee5b512 ("MAJOR: http: move http_txn out of struct stream"), the backtrace looks like this: Program terminated with signal SIGSEGV, Segmentation fault. #0

Re: PR flags on server error

Am 21.04.2016 um 23:47 schrieb Olivier Doucet: Because that buffer is also used for header appending. Yes but I do not add any ... I doubled the value to 2k but same error ... According to the configuration you posted here, you add 3 new headers: option forwardfor http-request

Re: PR flags on server error

Am 21.04.2016 um 22:53 schrieb Olivier Doucet: 2016-04-21 21:55 GMT+02:00 Lukas Tribus <lu...@gmx.net <mailto:lu...@gmx.net>>: Try bumping tune.maxrewrite or leave it at the default. Why will it matter ? I do not manipulate headers (at least on this very request

Re: PR flags on server error

Try bumping tune.maxrewrite or leave it at the default. Lukas

Re: Haproxy running on 100% CPU and slow downloads

Hi, Am 21.04.2016 um 08:11 schrieb Sachin Shetty: Hi, any hints to further isolate this - we have deferred the problem by adding all the cores we had, but I have a feeling that our request rate is not that high (7K per minute a peak) and it will show up again as traffic increases. Thanks

Re: HAProxy rejecting requests w/ extended characters in their URLs as bad

Hi, Am 19.04.2016 um 15:10 schrieb CJ Ess: That will work for now, in the future it wold be nice to have an option to allow non-control utf-8 characters in the URI without enabling all of the other stuff. Thats exactly what this option already does. There is fortunately no way in haproxy

Re: 100% cpu , epoll_wait()

Hi, Am 19.04.2016 um 09:39 schrieb Veiko Kukk: We use haproxy 1.6.3 (latest CentOS 6.7) and experience similar situation after some reloads (-sf). The old haproxy process does not exit and uses 100% cpu, strace showing: epoll_wait(0, {}, 200, 0) = 0 epoll_wait(0, {}, 200, 0)

Re: nbproc 1 vs >1 performance

Hi Willy, Am 14.04.2016 um 07:08 schrieb Willy Tarreau: Hi Lukas, On Thu, Apr 14, 2016 at 12:14:15AM +0200, Lukas Tribus wrote: For example, the following configuration load balances the traffic across all 40 processes, expected or not? frontend haproxy_test bind-process 1-40 bind

Re: nbproc 1 vs >1 performance

Hi Christian, Willy, Am 13.04.2016 um 12:58 schrieb Christian Ruppert: With the first config I get around ~30-33k requests/s on my test system, with the second conf (only the bind-process in the frontend section has been changed!) I just get around 26-28k requests per second. I could get

Re: Multiple front ends listening to the same address/port -- want a config error

Hi, Am 12.04.2016 um 19:39 schrieb Shawn Heisey: I copied a front end to set up a new service on my haproxy install. I changed the name of the front end, but forgot to change the port number on the "bind" option. Haproxy didn't complain about this configuration when I tested for validity, so

Re: TLS+PSK with HAProxy

Hi Roshan, Am 13.04.2016 um 06:19 schrieb Roshan Pradeep: Hi Could someone please shed some lights how to configure HAProxy to use TLS+PSK? I don't think TLS+PSK is supported. Lukas

Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi, Am 11.04.2016 um 23:20 schrieb Willy Tarreau: Excellent, thanks very much for confirming! I feel like I'm not completely obsolete yet if I can still spot such an issue by reading the code then write the reproducer :-) Nah, you're the buffer and polling man, you will never be obsolete :)

Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi, Am 07.04.2016 um 17:43 schrieb James Brown: Calling DES functions is kind of suspicious? I'd expect any clients made in the last decade or so to be negotiating AES (which is much, /much/ faster than DES) with either the default settings or any reasonably-secure custom settings. Can you

Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi, Am 05.04.2016 um 10:17 schrieb Nenad Merdanovic: I am not sure, as I haven't even be able to reliably reproduce it on 1.5 (though we are running with some backports from 1.6) as it seems to be traffic-pattern related. On one workload I exhibit instant and constant jump in CPU usage (from

Re: Haproxy running on 100% CPU and slow downloads

Hi, Am 05.04.2016 um 09:38 schrieb Sachin Shetty: Hi Lukas, Pavlos, Thanks for your response, more info as requested. 1. Attached conf with some obfuscation 2. Haproxy -vv HA-Proxy version 1.5.4 2014/09/02 Copyright 2000-2014 Willy Tarreau I would upgrade to something more

Re: Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi Nenad, I suggest you try reverting commit 7610073a. I have exhibited very similar issues and everything points to this commit (which was Willy's first suspect). So I assume this affects 1.6 and 1.7-dev as well, the bug is not specific to the 1.5 backport, right? Thanks, Lukas

Re: Haproxy running on 100% CPU and slow downloads

Hi Sachin, (due to email troubles on my side this may look like a new thread, sorry about that) > We have quite a few regex and acls in our config, is there a way to profile > haproxy and see what could be slowing it down? You can use strace for syscalls or ltrace for library calls to see

RE: Increased CPU usage after upgrading 1.5.15 to 1.5.16

> However, if I configure multiple listening sockets, to take advantage > of SO_REUSEPORT (and that is exactly what I have on my production > haproxy 1.5): > bind :443 process 1 ssl alpn http/1.1 crt /etc/ssl/snakeoil.pem > bind :443 process 2 ssl alpn http/1.1 crt /etc/ssl/snakeoil.pem > bind

RE: ssl offloading

> Hi list, > > what are your ideas about offloading of ssl? ssl inside haproxy is nice > but is very expensive. Why would you think that? Lukas

RE: Increased CPU usage after upgrading 1.5.15 to 1.5.16

> I am well aware that broken resumption is a bad thing. However, I've > looked though haproxy 1.5 code and I quite don't understand how > tickets are supposed to work with nbproc>1. The only code related to > TLS tickets in 1.5 is the code to disable them. Otherwise OpenSSL > defaults are used,

RE: Add servers without disruption

Hey guys, I think completely hitless reload is what the end goal should be. Config changes are not the only benefit, hitless binary upgrade would be terrific as well :) This should already work on the BSDs, only in Linux we have that race condition before close() and we may be able to mimic BSD

RE: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi Janusz, > So there is no difference. Session ID based resumption works ok, > ticket based resumption is kinda broken in both versions. Are tickets > supposed to work properly with nbproc>1? I just tested it here, ticket based resumption works fine for me with nbproxy>1 in both 1.5.16 and

RE: Increased CPU usage after upgrading 1.5.15 to 1.5.16

Hi Janusz, > Hello, > it seems I've stumbled upon a regression in haproxy 1.5.16. > > Short story: After upgrading 1.5.15 to 1.5.16 CPU usage increased > significantly (3-4 times) > > Long story: > > I have several haproxy servers running happily with 1.5.15 for quite > some time. Recently I've

RE: [PATCH] BUG/MEDIUM: Fix RFC5077 resumption when more than TLS_TICKETS_NO are present

Hi Nenad, >> But my tests with Vincents rfc5077-client indicate that we use all >> available keys in the file for decryption, not only TLS_TICKETS_NO. > > This is definitely not expected. Can you please let me know how you > tested this? I did some quick checks with openssl and it seems to be >

RE: [PATCH] BUG/MEDIUM: Fix RFC5077 resumption when more than TLS_TICKETS_NO are present

Hi Nenad, > Olivier Doucet reported the issue on the ML and tested that when using > more than TLS_TICKETS_NO keys in the file, the CPU usage is much higeher > than expected. > > Lukas Tribus then provided a test case which showed that resumption doesn't > work at all in tha

<    2   3   4   5   6   7   8   9   10   11   >