Re: [BUG] haproxy 1.8-last/master-worker/peers

[Willy Tarreau]

On Tue, Nov 28, 2017 at 05:08:53PM +0100, William Lallemand wrote:
> On Tue, Nov 28, 2017 at 02:56:55PM +0100, William Lallemand wrote:
> > On Tue, Nov 28, 2017 at 12:22:04PM +0100, Emmanuel Hocdet wrote:
> > > ok, i should have something strange because it's easy to reproduce in my 
> > > environnement.
> > > 
> > > When i look lsof i see on master:
> > > haproxy 21355 root4u  IPv4 39007164  0t0  TCP 10.101.20.4:943 
> > > (LISTEN)
> > > it's link to self ip configuration "peer L6_2 10.101.20.4:943"
> > > 
> > > Master listen on peer? really?
> > > on each reload (kill -USR2)  on more LISTEN appears
> > > 
> > 
> > I can reproduce easily the problem, the peers listener is not closed since 
> > I removed
> > the deinit from the master-worker code, however that does not explain why 
> > the old
> > worker does not quit.
> > 
> 
> Apparently this is reproducible without the master-worker, upon a reload with 
> a local peer,
> the previous process doesn't leave.

I can now reproduce it. It happens that my previous failed tests didn't
trigger it because no stick table was referencing the peers.

I could bisect it to this commit from a well-known bug author :

  commit 3e13cbafe2612dc026494d90ce8604f08cdaf58d
  Author: Willy Tarreau 
  Date:   Sun Oct 8 11:26:30 2017 +0200

MEDIUM: session: make use of the connection's destroy callback

Now we don't remove the session when a stream dies, instead we
detach the stream and let the mux decide to release the connection
and call session_free() instead.

I don't immediately see how it can be related, but I suspect that it
results in peers connections not properly being closed.

Willy

Re: [BUG] haproxy 1.8-last/master-worker/peers

[Willy Tarreau]

On Wed, Nov 29, 2017 at 10:41:18AM +0100, Willy Tarreau wrote:
> > Apparently this is reproducible without the master-worker, upon a reload 
> > with a local peer,
> > the previous process doesn't leave.
> 
> I can now reproduce it. It happens that my previous failed tests didn't
> trigger it because no stick table was referencing the peers.
> 
> I could bisect it to this commit from a well-known bug author :
> 
>   commit 3e13cbafe2612dc026494d90ce8604f08cdaf58d
>   Author: Willy Tarreau 
>   Date:   Sun Oct 8 11:26:30 2017 +0200
> 
> MEDIUM: session: make use of the connection's destroy callback
> 
> Now we don't remove the session when a stream dies, instead we
> detach the stream and let the mux decide to release the connection
> and call session_free() instead.
> 
> I don't immediately see how it can be related, but I suspect that it
> results in peers connections not properly being closed.

I understand now. It's embarrassing. Sessions are released only when
instanciated from a connection but never from an applet. So indeed we
keep a non-null job count which prevents the old process from quitting.

I'w working on this now.

Willy

Re: [PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Emmanuel Hocdet]

Hi Willy,

Can you consider the first patch (included here).
As Olivier said, the fix for ssl_fc_has_early need more works.

Can be backported to 1.8

++
Manu



0001-BUG-MINOR-ssl-CO_FL_EARLY_DATA-removal-is-managed-by.patch
Description: Binary data

Slow download speeds on SSL v/s plain http

[Sachin Shetty]

Hi,

We have been using haproxy in our production systems for a long time.
Recently we spotted a slowdown in downloads in SSL compared to plain
http.

We are able to reproduce this in a test setup which has no other traffic.
We have nbproc set according to the number of cpus

Haproxy has two front ends, one SSL and one plain http. Both forward to the
same webserver on local host to serve a 1GB file.

on https, we get about 150 MBPS speed, where as on the http backend we get
about 500MBPS. Everything else is same and all tests are on localhost so
there is no external network.

Haproxy version:
/usr/sbin/haproxy -vvv
HA-Proxy version 1.7.8 2017/07/07
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -DTCP_USER_TIMEOUT=18
  OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
USE_LUA=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[COMP] compression
[TRACE] trace
[SPOE] spoe

OS:
Linux l1webui-ratelimit01 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20
12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Thanks
Sachin

[PATCH]: BUILD FreeBSD and cpu afifnity

[David CARLIER]

Hi,

I intentionally did two separated patches about FreeBSD and
USE_CPU_AFFINITY. The first is just to fix a build issue, the second to
enable it by default.
The first patch might need to be backported to 1.8.

Hope it s good.

Kind regards.
From 52603a51797dafbd197de2558631ff134176cb5e Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 29 Nov 2017 11:02:32 +
Subject: [PATCH 1/2] BUILD/MINOR: haproxy : FreeBSD/cpu affinity needs
 pthread_np header

for pthread_*_np calls, pthread_np.h is needed under FreeBSD.
---
 src/haproxy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/haproxy.c b/src/haproxy.c
index 891a021d..a1fe550e 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -55,6 +55,7 @@
 #ifdef __FreeBSD__
 #include 
 #include 
+#include 
 #endif
 #endif
 
-- 
2.15.0

From 18e2aeaec99b573e53667959f8064870d2bd7837 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 29 Nov 2017 11:05:12 +
Subject: [PATCH 2/2] BUILD/MINOR: Makefile : enabling USE_CPU_AFFINITY

FreeBSD can handle cpuset matters just fine, we can hence enable it
by default as linux2628 TARGET.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 26b55db9..2acf5028 100644
--- a/Makefile
+++ b/Makefile
@@ -324,6 +324,7 @@ ifeq ($(TARGET),freebsd)
   USE_TPROXY = implicit
   USE_LIBCRYPT   = implicit
   USE_THREAD = implicit
+  USE_CPU_AFFINITY= implicit
 else
 ifeq ($(TARGET),osx)
   # This is for Mac OS/X
-- 
2.15.0

Re: [BUG] haproxy 1.8-last/master-worker/peers

[Willy Tarreau]

On Wed, Nov 29, 2017 at 11:54:28AM +0100, Willy Tarreau wrote:
> On Wed, Nov 29, 2017 at 10:41:18AM +0100, Willy Tarreau wrote:
> > > Apparently this is reproducible without the master-worker, upon a reload 
> > > with a local peer,
> > > the previous process doesn't leave.
> > 
> > I can now reproduce it. It happens that my previous failed tests didn't
> > trigger it because no stick table was referencing the peers.
> > 
> > I could bisect it to this commit from a well-known bug author :
> > 
> >   commit 3e13cbafe2612dc026494d90ce8604f08cdaf58d
> >   Author: Willy Tarreau 
> >   Date:   Sun Oct 8 11:26:30 2017 +0200
> > 
> > MEDIUM: session: make use of the connection's destroy callback
> > 
> > Now we don't remove the session when a stream dies, instead we
> > detach the stream and let the mux decide to release the connection
> > and call session_free() instead.
> > 
> > I don't immediately see how it can be related, but I suspect that it
> > results in peers connections not properly being closed.
> 
> I understand now. It's embarrassing. Sessions are released only when
> instanciated from a connection but never from an applet. So indeed we
> keep a non-null job count which prevents the old process from quitting.

Now fixed in both mainline and 1.8. Thanks for the report Manu!
Willy

Re: [PATCH]: BUILD FreeBSD and cpu afifnity

[Willy Tarreau]

On Wed, Nov 29, 2017 at 11:10:50AM +, David CARLIER wrote:
> I intentionally did two separated patches about FreeBSD and
> USE_CPU_AFFINITY. The first is just to fix a build issue, the second to
> enable it by default.
> The first patch might need to be backported to 1.8.

Thank you David, both merged and first one backported as per your
instructions.

Willy

Re: [PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Willy Tarreau]

Hi Manu,

On Wed, Nov 29, 2017 at 12:40:46PM +0100, Emmanuel Hocdet wrote:
> Can you consider the first patch (included here).
> As Olivier said, the fix for ssl_fc_has_early need more works.

OK now merged and backported, thanks!
Willy

Sticky-table contents is not distributed among peers

[Максим Куприянов]

Hi!

First of all I'd like to thank you for such a great software, as Haproxy
is. It is really one of the best opensource projects. And I'm your happy
user for many years :)

But now, I need help in troubleshooting. Recently I've tried to use
distributed sticky-tables, but for some reason they're not synced between
hosts (sometimes they really do, sometimes not).

I have a haproxy-config which looks like following:


peers slb_local

  peer slb1 2a02:6b8:0::1:1666

  peer slb2 2a02:6b8:0::2:1666


frontend test

…

  stick-table type ipv6 size 100 peers slb_local store
http_req_rate(10s),http_err_rate(10s),conn_rate(10s)

  http-request track-sc0 src

…

I have only one client on top of haproxy. Tcpdump shows some traffic over
port tcp/1666 between hosts (connections are established, no firewall
problems here). But counters differ both in 1.7.9 haproxy and 1.8.0
versions of haproxy.

When both balancers are serving requests:

‘echo "show table test" | socat stdio /var/run/haproxy.sock’ from slb1:

# table: test, type: ipv6, size:100, used:1

0x7f2a38592b84: key=fdee:fdee:0:3400::2:225 use=34 exp=0
conn_rate(1)=15905 http_req_rate(1)=15905 http_err_rate(1)=0

>From slb2:

# table: test, type: ipv6, size:100, used:1

0x7fccb877bb24: key=fdee:fdee:0:3400::2:225 use=28 exp=0
conn_rate(1)=15941 http_req_rate(1)=15941 http_err_rate(1)=0

When one of them is blocked with firewall from external traffic:

# table: test, type: ipv6, size:100, used:1

0x7f2a38592b84: key=fdee:fdee:0:3400::2:225 use=94 exp=0
conn_rate(1)=32786 http_req_rate(1)=32786 http_err_rate(1)=0

# table: test, type: ipv6, size:100, used:1

0x7fccb877bb24: key=fdee:fdee:0:3400::2:225 use=0 exp=0 conn_rate(1)=0
http_req_rate(1)=0 http_err_rate(1)=0

Version:
HA-Proxy version 1.8.0-4 2017/11/29
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_THREAD=1
USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_TFO=1 USE_NS=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.31 2012-07-06
Running on PCRE version : 8.31 2012-07-06
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

--
Best regards,
Maksim Kupriianov

Re: [PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Olivier Houchard]

On Mon, Nov 27, 2017 at 06:19:41PM +0100, Emmanuel Hocdet wrote:
> > Maybe the best is to add a new flag per conn_stream, CS_FL_WAITING_FOR_HS or
> > something, instead of relying on CO_FL_EARLY_DATA.
> > I think I'm going to do something like that.
> 
> I think it's a good idea, two different things to deal with one tag.
> 
> > That still doesn't help with your problem with TCP mode, though. I still 
> > want
> > the CO_FL_EARLY_DATA to be removed after the handshake, so that we don't
> > add the "Early-Data: 1" header if it is not needed. But it just occured
> > to me that I can easily fix that by adding the header, not only if 
> > CO_FL_EARLY_DATA is set, but if CO_FL_EARLY_SSL_HS or CO_FL_SSL_WAIT_HS is 
> > set.
> > That way we will both be happy :)
> 

So, this if my first cut at it. It basically does as I said.
Only thing you may be unhappy with, I made the sample fetch ssl_fc_has_early
return 0 if we had early data but the handshake happened, because the main
use case is to know if there are early data and if they're a potential
security risk.
If you can give me a case where we have a need a sample fetch to know there
were early data, even after the handshake, maybe we can introduce a new
sample fetch, ssl_fc_has_insecure_early, or something ?

Regards,

Olivier
>From bda3b7800677184ea19fb81f75f9a9b44c79efeb Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Mon, 27 Nov 2017 18:41:32 +0100
Subject: [PATCH 1/2] MINOR: early data: Don't rely on CO_FL_EARLY_DATA to wake
 up streams.

Instead of looking for CO_FL_EARLY_DATA to know if we have to try to wake
up a stream, because it is waiting for a SSL handshake, instead add a new
conn_stream flag, CS_FL_WAIT_FOR_HS. This way we don't have to rely on
CO_FL_EARLY_DATA, and we will only wake streams that are actually waiting.
---
 include/types/connection.h |  1 +
 src/mux_h2.c   | 24 ++--
 src/ssl_sock.c |  5 -
 src/stream_interface.c |  4 +++-
 4 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/include/types/connection.h b/include/types/connection.h
index a9d04474d..f220c42a9 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -69,6 +69,7 @@ enum {
 
CS_FL_ERROR = 0x0100,  /* a fatal error was reported */
CS_FL_EOS   = 0x1000,  /* End of stream */
+   CS_FL_WAIT_FOR_HS   = 0x0001,  /* This stream is waiting for 
handhskae */
 };
 
 /* cs_shutr() modes */
diff --git a/src/mux_h2.c b/src/mux_h2.c
index 4567b8ff0..4db90d4c8 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -54,6 +54,7 @@ static struct pool_head *pool_head_h2s;
 /* other flags */
 #define H2_CF_GOAWAY_SENT   0x0100  // a GOAWAY frame was successfully 
sent
 #define H2_CF_GOAWAY_FAILED 0x0200  // a GOAWAY frame failed to be sent
+#define H2_CF_WAIT_FOR_HS   0x0400  // We did check that at least a 
stream was waiting for handshake
 
 
 /* H2 connection state, in h2c->st0 */
@@ -2091,14 +2092,25 @@ static int h2_wake(struct connection *conn)
struct h2c *h2c = conn->mux_ctx;
 
/*
-* If we received early data, try to wake any stream, just in case
-* at least one of them was waiting for the handshake
+* If we received early data, and the handshake is done, wake
+* any stream that was waiting for it.
 */
-   if ((conn->flags & (CO_FL_EARLY_SSL_HS | CO_FL_EARLY_DATA | 
CO_FL_HANDSHAKE)) ==
-   CO_FL_EARLY_DATA) {
-   h2_wake_some_streams(h2c, 0, 0);
-   conn->flags &= ~CO_FL_EARLY_DATA;
+   if (!(h2c->flags & H2_CF_WAIT_FOR_HS) &&
+   (conn->flags & (CO_FL_EARLY_SSL_HS | CO_FL_HANDSHAKE | 
CO_FL_EARLY_DATA)) == CO_FL_EARLY_DATA) {
+   struct eb32_node *node;
+   struct h2s *h2s;
+
+   h2c->flags |= H2_CF_WAIT_FOR_HS;
+   node = eb32_lookup_ge(>streams_by_id, 1);
+
+   while (node) {
+   h2s = container_of(node, struct h2s, by_id);
+   if (h2s->cs->flags & CS_FL_WAIT_FOR_HS)
+   h2s->cs->data_cb->wake(h2s->cs);
+   node = eb32_next(node);
+   }
}
+
if (conn->flags & CO_FL_ERROR || conn_xprt_read0_pending(conn) ||
h2c->st0 == H2_CS_ERROR2 || h2c->flags & H2_CF_GOAWAY_FAILED ||
(eb_is_empty(>streams_by_id) && h2c->last_sid >= 0 &&
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index da1aecbcc..7c5fd6b10 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -8705,11 +8705,14 @@ enum act_return ssl_action_wait_for_hs(struct act_rule 
*rule, struct proxy *px,
struct session *sess, struct stream *s, 
int flags)
 {
struct connection *conn;
+   struct conn_stream *cs;
 
conn = objt_conn(sess->origin);
+   cs = objt_cs(s->si[0].end);
 
-   if (conn) {
+   if 

Seamless Restarts/Reloads in haproxy and master/worker-mode 1.8.

[Markus Rietzler]

i have upgraded to version 1.8. and so far everything works.

i have to questions about the new features:


1) seamless reload

one of the new features ist seamless restarts.
it is also said, that even an version upgrade should work.

how do i achieve this?

at the moment my startup script is very simple:

./sbin/haproxy -D -f ./haproxy.cfg

my reload looks like

./sbin/haproxy -f ./haproxy.cfg -p /opt/haproxy/var/pid -sf $(cat 
/opt/haproxy/var/pid)


how do i get a seamless reload? any special parameters or config needed or does 
it work out of the box?



2) master/worker-mode
haproxy will also support the so called worker mode with

sbin/haproxy -w 2

what is the benefit over the old/other one? do i need the master/worker-mode 
for seamless reloads?


thanxs

Markus

Re: Sticky-table contents is not distributed among peers

[Максим Куприянов]

Oh, I've found in documentation that "The pushed values overwrite remote
ones without aggregation." So identical src as a key is possibly not a good
choice at all. I've tried `hostname` as a key, but still see only one entry
with it's local hostname in tables on each host.

Maybe I'm doing something completely wrong and there is a better way. What
I really want is to get an acl for a backend selection based on
request-per-second rate of connections through the whole location with many
haproxy installations. How can I achieve this?

2017-11-29 19:39 GMT+05:00 Максим Куприянов :

> Hi!
>
> First of all I'd like to thank you for such a great software, as Haproxy
> is. It is really one of the best opensource projects. And I'm your happy
> user for many years :)
>
> But now, I need help in troubleshooting. Recently I've tried to use
> distributed sticky-tables, but for some reason they're not synced between
> hosts (sometimes they really do, sometimes not).
>
> --
> Best regards,
> Maksim Kupriianov
>

Re: [PATCH] BUG/MINOR: when master-worker is in daemon mode, detach from tty

[PiBa-NL]

Hi William,

When you have time, please take a look below & attached :) .

Op 29-11-2017 om 1:28 schreef William Lallemand:

Hi Pieter,

diff --git a/src/haproxy.c b/src/haproxy.c
index c3c8281..a811577 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2648,6 +2648,13 @@ int main(int argc, char **argv)
}
  
  	if (global.mode & (MODE_DAEMON | MODE_MWORKER)) {

+   if ((!(global.mode & MODE_QUIET) || (global.mode & MODE_VERBOSE)) 
&&
+   ((global.mode & (MODE_DAEMON | MODE_MWORKER)) == 
(MODE_DAEMON | MODE_MWORKER))) {
+   /* detach from the tty, this is required to properly 
daemonize. */
+   fclose(stdin); fclose(stdout); fclose(stderr);
+   global.mode &= ~MODE_VERBOSE;
+   global.mode |= MODE_QUIET; /* ensure that we won't say 
anything from now */
+   }
struct proxy *px;
struct peers *curpeers;
int ret = 0;

I need to check that again later, in my opinion it should be done after the
pipe() so we don't inherit the 0 and 1 FDs in the pipe,
FDs for the master-worker pipe can still be 0 and 1 if running in quiet 
mode as the stdin/stdout/stderr are still closed before creating the 
pipe then. Should the pipe be created earlier?
I've moved the code to just before the mworker_wait() in new attached 
patch. This should allow (all?) possible warnings to be output before 
closing stdX, and still 'seems' to work properly..

we also need to rely on
setsid() to do a proper tty detach.
I've added a setsid(), but i must admit i have no clue what its doing 
exactly...

  This is already done in -D mode without -W, maybe
this part of the code should me moved elsewhere, but we have to be careful not
to break the daemon mode w/o mworker.

I've tried most combinations of parameters like these:
1: -W
2: -W -q
3: -D -W
4: -D -W -q
5: -D
6: -D -q
7: -q
8: (without parameters)
Both by starting directly from a ssh console, and by running from my php 
script that reads the stdout/stderr output. And reloading it with USR2 
with the -W mode..
It seemed that the expected output or lack thereof was being produced in 
all cases.
But it preferably also needs to be tested under systemd itself as that 
is the intended use-case, which i did not test at all :/ ..
Also i did not change the config while running to include/exclude 
'quiet' or 'daemon' option or something like that. Seems like a odd 
thing to do..


I'm not sure if the attached patch is OK for you like this, or needs to 
be implemented completely differently.
I have made and tried to test the changed patch with above cases but am 
sure there are many things / combinations with other features i have not 
included..
If i need to change it slightly somehow please let me know, if you need 
time to look into it further, i can certainly wait :) i do not 'need' 
the feature urgently or perhaps won't need it at all..


Anyhow when you have time to look into it, i look forward to your 
feedback :) . Thanks in advance.


Regards,
PiBa-NL / Pieter
From c103dbd7837d49721ccadfb1aee9520e821a020f Mon Sep 17 00:00:00 2001
From: PiBa-NL 
Date: Tue, 28 Nov 2017 23:26:08 +0100
Subject: [PATCH] BUG/MINOR: when master-worker is in daemon mode, detach from
 tty

This allows a calling script to show the first startup output and know when to 
stop reading from stdout so haproxy can daemonize.
---
 src/haproxy.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 891a021..702501d 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2749,7 +2749,7 @@ int main(int argc, char **argv)
//lseek(pidfd, 0, SEEK_SET);  /* debug: emulate eglibc 
bug */
close(pidfd);
}
-
+   
/* We won't ever use this anymore */
free(global.pidfile); global.pidfile = NULL;
 
@@ -2757,6 +2757,16 @@ int main(int argc, char **argv)
if (global.mode & MODE_MWORKER) {
mworker_cleanlisteners();
deinit_pollers();
+
+   if ((!(global.mode & MODE_QUIET) || 
(global.mode & MODE_VERBOSE)) &&
+   ((global.mode & (MODE_DAEMON | 
MODE_MWORKER)) == (MODE_DAEMON | MODE_MWORKER))) {
+   /* detach from the tty, this is 
required to properly daemonize. */
+   fclose(stdin); fclose(stdout); 
fclose(stderr);
+   global.mode &= ~MODE_VERBOSE;
+   global.mode |= MODE_QUIET; /* ensure 
that we won't say anything from now */
+   setsid();
+   }
+   
mworker_wait();
 

openshift router with haproxy 1.8 and h2

[Aleksandar Lazic]

Hi all.

I have build today the openshift router with the brand new haproxy 1.8.0 
 and 'alpn h2,http/1.1'


https://gitlab.com/aleks001/openshift-ocp-router-hap18/blob/master/containerfiles/var/lib/haproxy/conf/haproxy-config.template#L223
https://gitlab.com/aleks001/openshift-ocp-router-hap18/blob/master/containerfiles/var/lib/haproxy/conf/haproxy-config.template#L267

You can use the image from docker hub with the following command in 
openshift.


*untested*
oc adm router 
--images=docker.io/me2digital/openshift-ocp-router-hap18:latest


Due to the fact that I'm not able to test it in deep would it be nice to 
get some feedback from you.


Best regards
Aleks

Re: HLS loadbalancing

[Moemen MHEDHBI]

Hi

HLS seems to be based on standard HTTP requests, so although I don't
know the details of the HLS protocol, I think HAProxy can do the Job.

You can use the diferent HAProxy timeouts to deal with long HTTP
sessions and you can rely on any HTTP header, cookie, .. to route
requests to the appropriate pool.

++


On 29/11/2017 08:09, Deon S wrote:
>
> Good day
>
> HAproxy looks like a very nice product. Was wondering if we can use it
> for HLS server load balancing. HLS is basically http file download but
> chunked. Connection times are way longer that normal and persistence
> will definitely be a key factor. Load balancer will ensure that
> connections are spread over a number of HLS streamers. Possibility we
> can enforce this with user accounts, when user connects we have some
> information and can then direct it to pool,  perhaps cookie.
>
> Search mailing list but found nothing about HLS.
>
> Regards
>
> Deon
>
> -- 
Hls

-- 
Moemen MHEDHBI