Re: Help! HAProxy randomly failing health checks!

Hey guys, just following up. Still running into the issue. From: Zachary Punches > Date: Friday, March 18, 2016 at 6:07 PM To: Igor Cicimov > Cc: Baptiste

Re: TLS Tickets and CPU usage

Hi again, 2016-03-24 21:15 GMT+01:00 Lukas Tribus : > Hi Nenad, > > > >> Well, its not supposed to look like this, there is clearly something > >> wrong. Master key fluctuates between the requests with TLS tickets > >> and the reuse collumn shows failure. > > > > Looks like

Re: TLS Tickets and CPU usage

Hey Lucas, On 03/24/2016 09:15 PM, Lukas Tribus wrote: > Hi Nenad, > > >>> Well, its not supposed to look like this, there is clearly something >>> wrong. Master key fluctuates between the requests with TLS tickets >>> and the reuse collumn shows failure. >> >> Looks like a haproxy bug, I think

RE: TLS Tickets and CPU usage

Hi Nenad, >> Well, its not supposed to look like this, there is clearly something >> wrong. Master key fluctuates between the requests with TLS tickets >> and the reuse collumn shows failure. > > Looks like a haproxy bug, I think I can reproduce it. > > Can you try with EXACTLY 3 keys in

RE: TLS Tickets and CPU usage

Hi Oliver, > 2016-03-24 17:12 GMT+01:00 Lukas Tribus > >: > > If thats not it, and no old haproxy instances are present after the > > reload, could you compile Vincent's rfc5077-client from [1]: > > Output can be find here > > :

Haproxy and FastCGI sockets

Hello, we're using Haproxy 1.5.5-1 to load balance traffic between frontentds running Lighttpd with mod_FastCGI and backends running a custom Perl app, based on FastCGI. Traffic between front and backends is not http - frontends open a socket to the VIP, and thus communicate to the backends.

Re: TLS Tickets and CPU usage

2016-03-24 17:12 GMT+01:00 Lukas Tribus : > > If thats not it, and no old haproxy instances are present after the > > reload, could you compile Vincent's rfc5077-client from [1]: > > Output can be find here > > : https://gist.github.com/anonymous/6ec7c863f497cfd849a4 > >

RE: TLS Tickets and CPU usage

> If thats not it, and no old haproxy instances are present after the > reload, could you compile Vincent's rfc5077-client from [1]: > Output can be find here > : https://gist.github.com/anonymous/6ec7c863f497cfd849a4 > (HTTP 500 error is normal, as you are using HEAD / HTTP/1.0 and our web >

RE: src_get_gpc0 seems not to work after commit f71f6f6

Hi, >> As below, I use stick-table for temporary acl. >> After commit f71f6f6, src_get_gpc0 seems not to work. >> >> So, I revert commit f71f6f6, and it works!! > > That's not a valid commit in the official haproxy repo, can you please > check the hash again? Its a valid hash in the haproxy-1.6

Re: src_get_gpc0 seems not to work after commit f71f6f6

Hi Seri, On 2016-03-23 08:40, Sehoon Kim wrote: Hi, As below, I use stick-table for temporary acl. After commit f71f6f6, src_get_gpc0 seems not to work. So, I revert commit f71f6f6, and it works!! That's not a valid commit in the official haproxy repo, can you please check the hash again?

Re: TLS Tickets and CPU usage

2016-03-24 12:57 GMT+01:00 Lukas Tribus : > > Ok, when you say CPU usage double do you mean the CPU usage after > > a reload/restart, or do you mean CPU usage in general (even after not > > reloading haproxy)? > > CPU is at 100% just after reload for more than 30s (was a few

RE: Weird stick-tables / peers behaviour

> Hi all, > > I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a > bunch of SMS because we're using stick-tables to track the connections > and monitor http_req_rate. The stick-tables data will be synced to the > other peers using the "peers" section. Possibly related to the

Weird stick-tables / peers behaviour

Hi all, I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a bunch of SMS because we're using stick-tables to track the connections and monitor http_req_rate. The stick-tables data will be synced to the other peers using the "peers" section. So I setup a test case using

Re: Exchange 2013 / NTLM Connections

Hi Graham, The http-keep-alive mode is recommended, with the "option prefer-last-server" (which should be implicitly set by HAProxy in your case). Hopefully you're not using the http-reuse option. 401 are normal and are part of the NTLM negociation. You should see a few of them at the beginning

RE: TLS Tickets and CPU usage

> Ok, when you say CPU usage double do you mean the CPU usage after  > a reload/restart, or do you mean CPU usage in general (even after not  > reloading haproxy)?  > CPU is at 100% just after reload for more than 30s (was a few seconds  > before) and then CPU usage stays doubled all the time. 

Exchange 2013 / NTLM Connections

Hi, I'm hoping someone can help with an Exchange 2013 / NTLM Authentication question. (My background is more on the networking side, so I'm finding my way a bit with HTTP related challenges...) We're currently running HA Proxy v1.6.4 and trying to use it in-front of an Exchange 2013 CAS

Re: CLEANUP: connection

On Thu, Mar 24, 2016 at 10:10:06AM +, David CARLIER wrote: > Sure :) but just "respected" the original form. OK I fixed it by hand and applied it. Willy

Re: TLS Tickets and CPU usage

Hi Lukas, 2016-03-24 11:15 GMT+01:00 Lukas Tribus : > > But CPU usage doubled ! I disabled it by adding again > > "ssl-default-bind-options no-tls-tickets" and CPU usage returned to > > normal. > > Ok, when you say CPU usage double do you mean the CPU usage after > a

RE: TLS Tickets and CPU usage

Hi Oliver, > Hello guys, > > I'm having troubles with HAProxy 1.6.3 and TLS ticket, so let me > explain here my case. > > I'm running HAProxy 1.6.3 (since december) and all was running fine. > TLS ticket was explicitely disabled. The only downside of this setup is > that after each

Re: CLEANUP: connection

Sure :) but just "respected" the original form. On 24 March 2016 at 10:05, Willy TARREAU wrote: > On Thu, Mar 24, 2016 at 09:34:48AM +, David CARLIER wrote: > > - if (!memcmp(line, "TCP4 ", 5) != 0) { > > + if (!(memcmp(line, "TCP4 ", 5) != 0)) { > > Wow. Scary

Re: CLEANUP: connection

On Thu, Mar 24, 2016 at 09:34:48AM +, David CARLIER wrote: > - if (!memcmp(line, "TCP4 ", 5) != 0) { > + if (!(memcmp(line, "TCP4 ", 5) != 0)) { Wow. Scary one. That said, couldn't you not avoid the double negation, like this ? :-) - if (!memcmp(line, "TCP4 ", 5) != 0) { +

TLS Tickets and CPU usage

Hello guys, I'm having troubles with HAProxy 1.6.3 and TLS ticket, so let me explain here my case. I'm running HAProxy 1.6.3 (since december) and all was running fine. TLS ticket was explicitely disabled. The only downside of this setup is that after each reload, I have a CPU spike for a few

CLEANUP: connection

Hi again, This is tiny one, this one I just spotted when I tried a build on FreeBSD with clang. clang detected unused functions as well but I did not dare to delete them, they might but just here "on hold" for future purposes (ie init_comp_ctx/deinit_comp_ctx and had_fd_isset in src/ev_poll.c).

Re: CLEANUP: chunk

Hi David, On Thu, Mar 24, 2016 at 09:16:19AM +, David CARLIER wrote: > Here a cleanup patch for the chunk_dup function. > hope it can be useful. Good catch, thank you. I've just merged it. That reminds me that there's still another one from you I need to check. Cheers, Willy

CLEANUP: chunk

Hi all, Here a cleanup patch for the chunk_dup function. hope it can be useful. Regards. From 3d904193dc041bad266fd04f69b50a66b8429f54 Mon Sep 17 00:00:00 2001 From: David Carlier Date: Wed, 23 Mar 2016 17:50:57 + Subject: [PATCH] CLEANUP: chunk: adding NULL check to

SO_REUSEPORT and process load distribution

Hello, I know SO_REUSEPORT has been discussed here a few times and I am aware that haproxy uses it to make restarts less disruptive, as a new instance can bind() to the listen ports without the need to stop the old instance first. But there is another aspect of SO_REUSEPORT that I have not yet

Re: DOC Patch: tune.vars.xxx-max-size

Hi Daniel, On Mon, Mar 21, 2016 at 09:56:10PM +0100, Daniel Schneller wrote: > >From 29bddd461c30bc850633350ac81e3c9fd7b56cb8 Mon Sep 17 00:00:00 2001 > From: Daniel Schneller > Date: Mon, 21 Mar 2016 20:46:57 +0100 > Subject: [PATCH] DOC: Clarify tunes.vars.xxx-max-size