Hi Milan,
On Mon, Jul 23, 2018 at 08:41:03AM +0200, Milan Petruzelka wrote:
> After weekend CLOSE_WAIT connections are still there.
Ah bad :-(
> What
> does cflg=0x80203300 in "show fd" mean?
These are the connection flags. You can figure them with contrib/debug/flags :
$ ./flags 0x80203300 |
Hi Cyril,
On Mon, Jul 23, 2018 at 10:04:34PM +0200, Cyril Bonté wrote:
> Some monthes ago, I began writing a compilation test script for haproxy, but
> as you may have noticed, I was not very available recently ;-)
Oh it happens to all of us unfortunately :-/
> I should be
> more available now.
Epiphany!
I was conflating the stick table with peers - thinking it was required in order
to not lose a connection if one of the HAProxy servers failed.
As it turns out, I can't "stick on src" as the users in the client's data
center will all present with the identical NAT address to the
Hi Norman,
Le 23/07/2018 à 18:36, Norman Branitsky a écrit :
My client’s environment had 3 HAProxy servers.
Due to a routing issue, my client’s users could only see the old HAProxy
1.5 server when connecting from their data center.
They could not see the 2 new HAProxy 1.7 servers.
The
Doing it with the patch does the equivalent of disabling it with the
option (realized there was an option afterwards).
We're more looking to know if the haproxy team is interested in getting
the issue addressed more than just getting the workaround
Thanks!
--
Julien Semaan
My client's environment had 3 HAProxy servers.
Due to a routing issue, my client's users could only see the old HAProxy 1.5
server when connecting from their data center.
They could not see the 2 new HAProxy 1.7 servers.
The routing issue was resolved last week and they could now see the 2 new
Hi Willy,
This patch is necessary to build with current BoringSSL (SSL_SESSION is now
opaque).
BoringSSL correctly matches OpenSSL 1.1.0 since 3b2ff028 for haproxy needs.
The patch revert part of haproxy 019f9b10 (openssl-compat.h).
This will not break openssl/libressl compat.
Can you consider
Hi Julien.
On 23/07/2018 09:07, Julien Semaan wrote:
Hi all,
We're currently using haproxy in our project PacketFence
(https://packetfence.org) and are currently experiencing an issue with
haproxy segfaulting when TCP splicing is enabled.
We're currently running version 1.8.9 and are
I need help with a current ACL and redirect that looks like this:
acl has_statistical_uri path_beg -i /statistical
http-request redirect code 301 prefix
https://statistical.example.com/statisticalinsight if has_statistical_uri
When the request like this comes in:
Hi,
I'm running HAproxy (1.7 or 1.8) inside Docker containers, through by
SystemD unit files on the host.
I would like to force HAproxy to reload certificates (bind ssl crt) with
minimal downtime whenever they are renewed on disk (another process inside
the container).
I tried to send HUP
Hi all,
We're currently using haproxy in our project PacketFence
(https://packetfence.org) and are currently experiencing an issue with
haproxy segfaulting when TCP splicing is enabled.
We're currently running version 1.8.9 and are occasionally getting
segfaults on this specific line in
Hi,
I've compiled latest haproxy 1.8.12 from Git repo (HAProxy version
1.8.12-5e100b-15, released 2018/07/20) with latest h2 patches and extended
h2 debug info. And after some time I caught one CLOSE_WAIT connection. Here
is extended show fd debug:
25 : st=0x20(R:pra W:pRa) ev=0x00(heopi)
On Fri, 20 Jul 2018 at 14:36, Milan Petruželka wrote:
>
> I've applied both patches to vanilla haproxy 1.8.12. I'll leave it running
> and report back.
>
>
Hi,
After weekend CLOSE_WAIT connections are still there. What
does cflg=0x80203300 in "show fd" mean? FDs with cflg=0x80203300 are
13 matches
Mail list logo
