Re: [PATCH] MINOR: boringssl: basic support for OCSP Stapling

Hi Willy, This patch only applies to boringssl. Could you merge them? ++ Emmanuel > Le 29 mars 2017 à 16:46, Emmanuel Hocdet a écrit : > > > Use boringssl SSL_CTX_set_ocsp_response to set OCSP response from file with > '.ocsp' extension. CLI update is not supported. > >

Re: truncated request in log lines

On 18 May 2017, at 6:36, Willy Tarreau wrote: > Hi Stéphane, > > On Thu, May 18, 2017 at 02:31:07AM +0200, Stéphane Cottin wrote: >> patch attached. > > Nice, that was fast :-) Nobody have time, I just take care of things as they flow :) > > The patch looks pretty good. Just two things : > -

Re: truncated request in log lines

On Thu, May 18, 2017 at 08:58:41AM +0200, Stéphane Cottin wrote: > > Nice, that was fast :-) > > Nobody have time, I just take care of things as they flow :) you're right! > Sorry, I didn't read the CONTRIBUTING, RTFM me. no pb. > Hope this one is better. Definitely. The most suitable form

Re: haproxy "inter" and "timeout check", retries and "fall"

Hi Bryan, For reference: defaults modehttp log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch

Re: [PATCH] MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list

Hi, Same patch, split in 3 parts for better understanding. > Le 12 mai 2017 à 15:05, Emmanuel Hocdet a écrit : > > Hi, > > This patch depend of " [Patches] TLS methods configuration reworked ». > > Actually it will only work with BoringSSL because haproxy use a special >

Re: Bug: DNS changes in 1.7.3+ break UNIX socket stats in daemon mode with resolvers on FreeBSD

On 05/12/2017 09:50 AM, Willy Tarreau wrote: > On Fri, May 12, 2017 at 10:20:56AM +0200, Frederic Lecaille wrote: >> Here is a more well-formed patch. >> Feel free to amend the commit message if not enough clear ;) > > It was clear enough, thanks. I added the mention of the faulty commit, > that

1.7.5 503 Timeouts with SNI backend

We have the following backend configuration: backend clientsite_ember server cf foobar.cloudfront.net:443 ssl verify required sni str( foobar.cloudfront.net) ca-file /etc/ssl/certs/ca-certificates.crt This has been working great with 1.7.2 since February. I upgraded to 1.7.5 yesterday and

Re: 1.7.5 503 Timeouts with SNI backend

That’s incredibly insightful of you. I’ll set up a resolver for all of my CF uses and report back if I can repro this apart from that config fix. Thanks! On May 18, 2017 at 3:42:35 PM, Michael Ezzell (mich...@ezzell.net) wrote: On May 18, 2017 3:07 PM, "Ryan Schlesinger"

Re: [Patches] TLS methods configuration reworked

Hi all, Le 12/05/2017 à 15:13, Willy Tarreau a écrit : Hi guys, On Tue, May 09, 2017 at 11:21:36AM +0200, Emeric Brun wrote: It seems to do what we want, so we can merge it. So the good news is that this patch set now got merged :-) Commit 5db33cbdc4 [1] seems to have broken the

Re: haproxy consuming 100% cpu - epoll loop

On 2017/1/17 17:02, Willy Tarreau wrote: > Hi Patrick, > > On Tue, Jan 17, 2017 at 02:33:44AM +, Patrick Hemmer wrote: >> So on one of my local development machines haproxy started pegging the >> CPU at 100% >> `strace -T` on the process just shows: >> >> ... >> epoll_wait(0, {}, 200, 0)

haproxy doesn't restart after segfault on systemd

So we had an incident today where haproxy segfaulted and our site went down. Unfortunately we did not capture a core, and the segfault message logged to dmesg just showed it inside libc. So there's likely not much we can do here. We'll be making changes to ensure we capture a core in the future.

Re: 1.7.5 503 Timeouts with SNI backend

On May 18, 2017 3:07 PM, "Ryan Schlesinger" wrote: We have the following backend configuration: backend clientsite_ember server cf foobar.cloudfront.net:443 ssl verify required sni str( foobar.cloudfront.net) ca-file /etc/ssl/certs/ca-certificates.crt This has been

Re: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

Hi Krishna, On Fri, May 19, 2017 at 09:47:52AM +0530, Krishna Kumar (Engineering) wrote: > I saw many similar issues posted earlier by others, but could not find a > thread > where this is resolved or fixed in a newer release. We are using Ubuntu > 16.04 > with distro HAProxy (1.6.3), and see

HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

Hi, First of all, thanks for a great product that is working extremely well for Flipkart! I saw many similar issues posted earlier by others, but could not find a thread where this is resolved or fixed in a newer release. We are using Ubuntu 16.04 with distro HAProxy (1.6.3), and see that

Re: haproxy consuming 100% cpu - epoll loop

Hi Patrick, On Thu, May 18, 2017 at 05:44:30PM -0400, Patrick Hemmer wrote: > > On 2017/1/17 17:02, Willy Tarreau wrote: > > Hi Patrick, > > > > On Tue, Jan 17, 2017 at 02:33:44AM +, Patrick Hemmer wrote: > >> So on one of my local development machines haproxy started pegging the > >> CPU at

Re: [Patches] TLS methods configuration reworked

Hi Cyril, On Thu, May 18, 2017 at 11:02:29PM +0200, Cyril Bonté wrote: > Hi all, > > Le 12/05/2017 à 15:13, Willy Tarreau a écrit : > > Hi guys, > > > > On Tue, May 09, 2017 at 11:21:36AM +0200, Emeric Brun wrote: > > > It seems to do what we want, so we can merge it. > > > > So the good news

Re: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

Hi Willy, Thanks for your response/debug details. > It seems that something is preventing the connection close from being > considered, while the task is woken up on a timeout and on I/O. This > exactly reminds me of the client-fin/server-fin bug in fact. Do you > have any of these timeouts in

Re: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

❦ 19 mai 2017 07:04 +0200, Willy Tarreau  : >> I saw many similar issues posted earlier by others, but could not >> find a thread where this is resolved or fixed in a newer release. We >> are using Ubuntu 16.04 with distro HAProxy (1.6.3), and see that >> HAProxy spins at 100% with