tcp log srv_queue meaning

[linbo liao]

Hi,

I tried to figure out the srv_queue meaning in tcp log, I searched google
and mailing-list but without any result.

The document says

"srv_queue" is the total number of requests which were processed before
this one in the server queue. It is zero when the request has not gone
through the server queue. It makes it possible to estimate the approximate
server's response time by dividing the time spent in queue by the number of
requests in the queue.

Take this scenario:

Before current request reach the queue, there are 100 requests go
through this queue.

When current request reach the queue, still 20 request are waiting for handle.

So srv_queue is 80 or 20?

Thanks,

Linbo

Re: Problems with SNI config

[Jeremy Utley]

Thanks for the suggestion, Brian!  First off, IUS *IS* actually on our
allowed list, so I upgraded to the IUS haproxy RPM v1.7.3 (Our local repo
copy does not have 1.7.4 sync'd into it yet - I didn't even realize haproxy
was in the IUS repo).  I also converted my configuration to be like you
indicated, and I am unfortunately still having the same issue.  Here is my
new front-end configuration (sanitized):

frontend https-8443
bind 192.168.1.1:8443 ssl crt /etc/haproxy/certs/
acl site01 hdr(host) -i site01.domain.com
acl site02 hdr(host) -i site02.domain.com
use_backend site01 if site01
use_backend site02 if site02

If I delete the two use_backend lines, and add a default_backend line, it
works properly.

For additional reference, here are the two backends and my defaults section
as well:

backend site01
balance roundrobin
server server01 192.168.1.2:80

backend site02
balance roundrobin
server server02 192.168.1.3:80

(In this implementation, we're using it more for the proxy functions than
we are the HA functions).

defaults
modehttp
log global
option  httplog
option  dontlognull
option http-server-close
option forwardfor
option  redispatch
retries 3
timeout http-request10s
timeout queue   1m
timeout connect 10s
timeout client  1m
timeout server  1m
timeout http-keep-alive 10s
timeout check   10s
maxconn 3000


Also, looking at the log file, all I see is:

Apr 13 16:43:37 tc-vpn01 haproxy[8986]: 192.168.1.100:59689
[13/Apr/2017:16:43:37.874] https-8443~ https-8443/ -1/-1/-1/-1/0 503
212 - - SC-- 0/0/0/0/0 0/0 "GET /favicon.ico HTTP/1.1"

Anyone with any ideas?

Thanks,

Jeremy

On Thu, Apr 13, 2017 at 11:41 AM, Gibson, Brian (IMS) 
wrote:

> I’ve not tried using ACLs in curly brackets like you are, but I can
> confirm that this configuration works for me
>
>
>
> acl name1 hdr(host) -i www.example.org
>
> acl name2 hdr(host) -i www.example-other.org
>
>
>
> use_backend backend1 if name1
>
> use_backend backend2 if name2
>
>
>
> I use this code specifically to do what you’re trying to do, though I’m
> using the latest stable build.  I’m pretty sure this code should work in
> 1.5 though as well.
>
>
>
> Also if you can’t use self compiled stuff, can you use something like IUS?
> https://ius.io/
>
>
>
> *From:* Jeremy Utley [mailto:jer...@ifuzioncorp.com]
> *Sent:* Thursday, April 13, 2017 12:29 PM
> *To:* haproxy@formilux.org
> *Subject:* Problems with SNI config
>
>
>
> Hello all!
>
>
>
> I'm trying to convert an Apache reverse proxy setup over to using HAProxy,
> but am running into issues with SNI.  I followed
> http://stuff-things.net/2016/11/30/haproxy-sni/  to set this up, but it's
> not working, and I have not yet been able to figure out why.
>
>
>
> HAProxy version:  1.5.4-3 installed from the EPEL repo on Centos 6 (Policy
> here forbids self-compiled versions, so we are limited to only what's
> available to us in EPEL)
>
>
>
> I've narrowed down the problem to my frontend definition - if I simplify
> the front-end to not do SNI, it works fine to either backend.  If I add a
> default_backend definition, it goes to the default backend no matter which
> hostname I provide.  Without the default_backend in the frontend
> configuration, I get a 503 error from the proxy.  So something is
> definately not right with my SNI configuration, but I certainly can not
> find it!
>
>
>
> Here is a sanitized version of my frontend definition in haproxy.cfg:
>
>
>
> frontend https-8443
>
> bind 192.168.1.1:8443 ssl crt /etc/haproxy/certs/
>
> use_backend site1 if { hdr(host) -i site1.domain.com }
>
> use_backend site2 if { hdr(host) -i site2.domain.com }
>
>
>
>
>
> We will eventually have something like 20-30 different SSL sites in this
> configuration, along with some IP-based ACLs as well, but I'm not to that
> point as of yet.  I am simply trying to get SNI working, to direct to a
> different backend depending on the hostname requested (which, according to
> my reading, should be perfectly doable with haproxy.
>
>
>
> Anybody got any ideas of what I'm doing wrong?
>
>
>
> Thanks for your time!
>
>
>
> Jeremy Utley
>
> --
>
> Information in this e-mail may be confidential. It is intended only for
> the addressee(s) identified above. If you are not the addressee(s), or an
> employee or agent of the addressee(s), please note that any dissemination,
> distribution, or copying of this communication is strictly prohibited. If
> you have received this e-mail in error, please notify the sender of the
> error.
>

RE: Problems with SNI config

[Gibson, Brian (IMS)]

I’ve not tried using ACLs in curly brackets like you are, but I can confirm 
that this configuration works for me

acl name1 hdr(host) -i www.example.org
acl name2 hdr(host) -i www.example-other.org

use_backend backend1 if name1
use_backend backend2 if name2

I use this code specifically to do what you’re trying to do, though I’m using 
the latest stable build.  I’m pretty sure this code should work in 1.5 though 
as well.

Also if you can’t use self compiled stuff, can you use something like IUS? 
https://ius.io/

From: Jeremy Utley [mailto:jer...@ifuzioncorp.com]
Sent: Thursday, April 13, 2017 12:29 PM
To: haproxy@formilux.org
Subject: Problems with SNI config

Hello all!

I'm trying to convert an Apache reverse proxy setup over to using HAProxy, but 
am running into issues with SNI.  I followed 
http://stuff-things.net/2016/11/30/haproxy-sni/  to set this up, but it's not 
working, and I have not yet been able to figure out why.

HAProxy version:  1.5.4-3 installed from the EPEL repo on Centos 6 (Policy here 
forbids self-compiled versions, so we are limited to only what's available to 
us in EPEL)

I've narrowed down the problem to my frontend definition - if I simplify the 
front-end to not do SNI, it works fine to either backend.  If I add a 
default_backend definition, it goes to the default backend no matter which 
hostname I provide.  Without the default_backend in the frontend configuration, 
I get a 503 error from the proxy.  So something is definately not right with my 
SNI configuration, but I certainly can not find it!

Here is a sanitized version of my frontend definition in haproxy.cfg:

frontend https-8443
bind 192.168.1.1:8443 ssl crt /etc/haproxy/certs/
use_backend site1 if { hdr(host) -i 
site1.domain.com }
use_backend site2 if { hdr(host) -i 
site2.domain.com }


We will eventually have something like 20-30 different SSL sites in this 
configuration, along with some IP-based ACLs as well, but I'm not to that point 
as of yet.  I am simply trying to get SNI working, to direct to a different 
backend depending on the hostname requested (which, according to my reading, 
should be perfectly doable with haproxy.

Anybody got any ideas of what I'm doing wrong?

Thanks for your time!

Jeremy Utley



Information in this e-mail may be confidential. It is intended only for the 
addressee(s) identified above. If you are not the addressee(s), or an employee 
or agent of the addressee(s), please note that any dissemination, distribution, 
or copying of this communication is strictly prohibited. If you have received 
this e-mail in error, please notify the sender of the error.

Problems with SNI config

[Jeremy Utley]

Hello all!

I'm trying to convert an Apache reverse proxy setup over to using HAProxy,
but am running into issues with SNI.  I followed
http://stuff-things.net/2016/11/30/haproxy-sni/  to set this up, but it's
not working, and I have not yet been able to figure out why.

HAProxy version:  1.5.4-3 installed from the EPEL repo on Centos 6 (Policy
here forbids self-compiled versions, so we are limited to only what's
available to us in EPEL)

I've narrowed down the problem to my frontend definition - if I simplify
the front-end to not do SNI, it works fine to either backend.  If I add a
default_backend definition, it goes to the default backend no matter which
hostname I provide.  Without the default_backend in the frontend
configuration, I get a 503 error from the proxy.  So something is
definately not right with my SNI configuration, but I certainly can not
find it!

Here is a sanitized version of my frontend definition in haproxy.cfg:

frontend https-8443
bind 192.168.1.1:8443 ssl crt /etc/haproxy/certs/
use_backend site1 if { hdr(host) -i site1.domain.com }
use_backend site2 if { hdr(host) -i site2.domain.com }


We will eventually have something like 20-30 different SSL sites in this
configuration, along with some IP-based ACLs as well, but I'm not to that
point as of yet.  I am simply trying to get SNI working, to direct to a
different backend depending on the hostname requested (which, according to
my reading, should be perfectly doable with haproxy.

Anybody got any ideas of what I'm doing wrong?

Thanks for your time!

Jeremy Utley

Re: [RFC][PATCHES] seamless reload

[Olivier Houchard]

On Thu, Apr 13, 2017 at 06:00:59PM +0200, Conrad Hoffmann wrote:
> On 04/13/2017 05:10 PM, Olivier Houchard wrote:
> > On Thu, Apr 13, 2017 at 04:59:26PM +0200, Conrad Hoffmann wrote:
> >> Sure, here it is ;P
> >>
> >> I now get a segfault (on reload):
> >>
> >> *** Error in `/usr/sbin/haproxy': corrupted double-linked list:
> >> 0x05b511e0 ***
> >>
> >> Here is the backtrace, retrieved from the core file:
> >>
> >> (gdb) bt
> >> #0  0x7f4c92801067 in __GI_raise (sig=sig@entry=6) at
> >> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> >> #1  0x7f4c92802448 in __GI_abort () at abort.c:89
> >> #2  0x7f4c9283f1b4 in __libc_message (do_abort=do_abort@entry=1,
> >> fmt=fmt@entry=0x7f4c92934210 "*** Error in `%s': %s: 0x%s ***\n") at
> >> ../sysdeps/posix/libc_fatal.c:175
> >> #3  0x7f4c9284498e in malloc_printerr (action=1, str=0x7f4c929302ec
> >> "corrupted double-linked list", ptr=) at malloc.c:4996
> >> #4  0x7f4c92845923 in _int_free (av=0x7f4c92b71620 ,
> >> p=, have_lock=0) at malloc.c:3996
> >> #5  0x00485850 in tcp_find_compatible_fd (l=0xaaed20) at
> >> src/proto_tcp.c:812
> >> #6  tcp_bind_listener (listener=0xaaed20, errmsg=0x7ffccc774e10 "",
> >> errlen=100) at src/proto_tcp.c:878
> >> #7  0x00493ce1 in start_proxies (verbose=0) at src/proxy.c:793
> >> #8  0x004091ec in main (argc=21, argv=0x7ffccc775168) at
> >> src/haproxy.c:1942
> > 
> > Ok, yet another stupid mistake, hopefully the attached patch fixes this :)
> > 
> > Thanks !
> > 
> > Olivier
> 
> 
> It does indeed! Not only does it work now, the result is impressive! Not a
> single dropped request even when aggressively reloading under substantial 
> load!
> 
> You certainly gave me an unexpected early easter present here :)
> 
> I will now head out, but I am planning on installing a 1.8 version with
> your patches on our canary pool (which receives a small amount of
> production traffic to test changes) after the holidays. I will happily test
> anything else that might be helpful for you. I will also set up a proper
> load test inside our data center then, but I expect no surprises there (my
> current tests were done over a VPN link, somewhat limiting the achievable
> throughput).
> 
> Once more, thank you so much! This will greatly simplify much of our
> operations. If there is anything else we can help test, let me know :)

Pfew, at least :) Thanks a lot for your patience, and doing all that testing !

Olivier

Re: [RFC][PATCHES] seamless reload

[Conrad Hoffmann]

On 04/13/2017 05:10 PM, Olivier Houchard wrote:
> On Thu, Apr 13, 2017 at 04:59:26PM +0200, Conrad Hoffmann wrote:
>> Sure, here it is ;P
>>
>> I now get a segfault (on reload):
>>
>> *** Error in `/usr/sbin/haproxy': corrupted double-linked list:
>> 0x05b511e0 ***
>>
>> Here is the backtrace, retrieved from the core file:
>>
>> (gdb) bt
>> #0  0x7f4c92801067 in __GI_raise (sig=sig@entry=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> #1  0x7f4c92802448 in __GI_abort () at abort.c:89
>> #2  0x7f4c9283f1b4 in __libc_message (do_abort=do_abort@entry=1,
>> fmt=fmt@entry=0x7f4c92934210 "*** Error in `%s': %s: 0x%s ***\n") at
>> ../sysdeps/posix/libc_fatal.c:175
>> #3  0x7f4c9284498e in malloc_printerr (action=1, str=0x7f4c929302ec
>> "corrupted double-linked list", ptr=) at malloc.c:4996
>> #4  0x7f4c92845923 in _int_free (av=0x7f4c92b71620 ,
>> p=, have_lock=0) at malloc.c:3996
>> #5  0x00485850 in tcp_find_compatible_fd (l=0xaaed20) at
>> src/proto_tcp.c:812
>> #6  tcp_bind_listener (listener=0xaaed20, errmsg=0x7ffccc774e10 "",
>> errlen=100) at src/proto_tcp.c:878
>> #7  0x00493ce1 in start_proxies (verbose=0) at src/proxy.c:793
>> #8  0x004091ec in main (argc=21, argv=0x7ffccc775168) at
>> src/haproxy.c:1942
> 
> Ok, yet another stupid mistake, hopefully the attached patch fixes this :)
> 
> Thanks !
> 
> Olivier


It does indeed! Not only does it work now, the result is impressive! Not a
single dropped request even when aggressively reloading under substantial load!

You certainly gave me an unexpected early easter present here :)

I will now head out, but I am planning on installing a 1.8 version with
your patches on our canary pool (which receives a small amount of
production traffic to test changes) after the holidays. I will happily test
anything else that might be helpful for you. I will also set up a proper
load test inside our data center then, but I expect no surprises there (my
current tests were done over a VPN link, somewhat limiting the achievable
throughput).

Once more, thank you so much! This will greatly simplify much of our
operations. If there is anything else we can help test, let me know :)

Cheers,
Conrad
-- 
Conrad Hoffmann
Traffic Engineer

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany

Managing Director: Alexander Ljung | Incorporated in England & Wales
with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
HRB 110657B

Re: Lua memory allocator

[Willy Tarreau]

On Thu, Apr 13, 2017 at 05:02:54PM +0200, Willy Tarreau wrote:
> On Thu, Apr 13, 2017 at 12:37:19PM +0200, Thierry Fournier wrote:
> > Good catch. I read the code of the Lua function luaL_newstate, and I
> > approve your change because this function dos exactly the same job, but
> > with a libc memory allocator. Note that a few lines after after your patch
> > (about 15 lines), I call the function "lua_setallocf()" which set again
> > the memory allocator. I think that this line becomes useless and it will
> > be better to remove it.
> 
> Yes it's after I noticed it that I started to understand the problem. But
> it's unsure to me whether we can get rid of it, as I understood that the
> first one stated what allocator to use during that call. You may be right,
> it probably doesn't make much sense. I can test however, it's easy.

OK I could confirm that you're right so I removed this call and merged
the change now.

thanks!
Willy

Re: [RFC][PATCHES] seamless reload

[Olivier Houchard]

On Thu, Apr 13, 2017 at 04:59:26PM +0200, Conrad Hoffmann wrote:
> Sure, here it is ;P
> 
> I now get a segfault (on reload):
> 
> *** Error in `/usr/sbin/haproxy': corrupted double-linked list:
> 0x05b511e0 ***
> 
> Here is the backtrace, retrieved from the core file:
> 
> (gdb) bt
> #0  0x7f4c92801067 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x7f4c92802448 in __GI_abort () at abort.c:89
> #2  0x7f4c9283f1b4 in __libc_message (do_abort=do_abort@entry=1,
> fmt=fmt@entry=0x7f4c92934210 "*** Error in `%s': %s: 0x%s ***\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x7f4c9284498e in malloc_printerr (action=1, str=0x7f4c929302ec
> "corrupted double-linked list", ptr=) at malloc.c:4996
> #4  0x7f4c92845923 in _int_free (av=0x7f4c92b71620 ,
> p=, have_lock=0) at malloc.c:3996
> #5  0x00485850 in tcp_find_compatible_fd (l=0xaaed20) at
> src/proto_tcp.c:812
> #6  tcp_bind_listener (listener=0xaaed20, errmsg=0x7ffccc774e10 "",
> errlen=100) at src/proto_tcp.c:878
> #7  0x00493ce1 in start_proxies (verbose=0) at src/proxy.c:793
> #8  0x004091ec in main (argc=21, argv=0x7ffccc775168) at
> src/haproxy.c:1942

Ok, yet another stupid mistake, hopefully the attached patch fixes this :)

Thanks !

Olivier
>From 7c7fe0c00129d60617cba786cbec7bbdd9ce08f8 Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Thu, 13 Apr 2017 17:06:53 +0200
Subject: [PATCH 12/12] BUG/MINOR: Properly remove the xfer_sock from the
 linked list.

Doubly linked list are hard to get right.
---
 src/proto_tcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index f558f00..57d6fc1 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -806,7 +806,7 @@ static int tcp_find_compatible_fd(struct listener *l)
if (xfer_sock->prev)
xfer_sock->prev->next = xfer_sock->next;
if (xfer_sock->next)
-   xfer_sock->next->prev = xfer_sock->next->prev;
+   xfer_sock->next->prev = xfer_sock->prev;
free(xfer_sock->iface);
free(xfer_sock->namespace);
free(xfer_sock);
-- 
2.9.3

Re: Lua memory allocator

[Willy Tarreau]

On Thu, Apr 13, 2017 at 12:37:19PM +0200, Thierry Fournier wrote:
> Good catch. I read the code of the Lua function luaL_newstate, and I
> approve your change because this function dos exactly the same job, but
> with a libc memory allocator. Note that a few lines after after your patch
> (about 15 lines), I call the function "lua_setallocf()" which set again
> the memory allocator. I think that this line becomes useless and it will
> be better to remove it.

Yes it's after I noticed it that I started to understand the problem. But
it's unsure to me whether we can get rid of it, as I understood that the
first one stated what allocator to use during that call. You may be right,
it probably doesn't make much sense. I can test however, it's easy.

Thanks!
Willy

Re: [RFC][PATCHES] seamless reload

[Conrad Hoffmann]

On 04/13/2017 03:50 PM, Olivier Houchard wrote:
> On Thu, Apr 13, 2017 at 03:06:47PM +0200, Conrad Hoffmann wrote:
>>
>>
>> On 04/13/2017 02:28 PM, Olivier Houchard wrote:
>>> On Thu, Apr 13, 2017 at 12:59:38PM +0200, Conrad Hoffmann wrote:
 On 04/13/2017 11:31 AM, Olivier Houchard wrote:
> On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
>> Hi Olivier,
>>
>> On 04/12/2017 06:09 PM, Olivier Houchard wrote:
>>> On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
 On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
> Hi again,
>
> so I tried to get this to work, but didn't manage yet. I also don't 
> quite
> understand how this is supposed to work. The first haproxy process is
> started _without_ the -x option, is that correct? Where does that 
> instance
> ever create the socket for transfer to later instances?
>
> I have it working now insofar that on reload, subsequent instances are
> spawned with the -x option, but they'll just complain that they can't 
> get
> anything from the unix socket (because, for all I can tell, it's not
> there?). I also can't see the relevant code path where this socket 
> gets
> created, but I didn't have time to read all of it yet.
>
> Am I doing something wrong? Did anyone get this to work with the
> systemd-wrapper so far?
>
> Also, but this might be a coincidence, my test setup takes a huge
> performance penalty just by applying your patches (without any 
> reloading
> whatsoever). Did this happen to anybody else? I'll send some numbers 
> and
> more details tomorrow.
>

 Ok I can confirm the performance issues, I'm investigating.

>>>
>>> Found it, I was messing with SO_LINGER when I shouldn't have been.
>>
>> 
>>
>> thanks a lot, I can confirm that the performance regression seems to be 
>> gone!
>>
>> I am still having the other (conceptual) problem, though. Sorry if this 
>> is
>> just me holding it wrong or something, it's been a while since I dug
>> through the internals of haproxy.
>>
>> So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
>> which in turn starts haproxy in daemon mode, giving us a process tree 
>> like
>> this (path and file names shortened for brevity):
>>
>> \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
>> \_ /u/s/haproxy-master
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>>
>> Now, in our config file, we have something like this:
>>
>> # expose admin socket for each process
>>   stats socket ${STATS_ADDR}   level admin process 1
>>   stats socket ${STATS_ADDR}-2 level admin process 2
>>   stats socket ${STATS_ADDR}-3 level admin process 3
>>   stats socket ${STATS_ADDR}-4 level admin process 4
>>   stats socket ${STATS_ADDR}-5 level admin process 5
>>   stats socket ${STATS_ADDR}-6 level admin process 6
>>   stats socket ${STATS_ADDR}-7 level admin process 7
>>   stats socket ${STATS_ADDR}-8 level admin process 8
>>   stats socket ${STATS_ADDR}-9 level admin process 9
>>   stats socket ${STATS_ADDR}-10 level admin process 10
>>   stats socket ${STATS_ADDR}-11 level admin process 11
>>   stats socket ${STATS_ADDR}-12 level admin process 12
>>
>> Basically, we have a dedicate admin socket for each ("real") process, as 
>> we
>> need to be able to talk to each process individually. So I was wondering:
>> which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
>> thought it would have to be a special stats socket in the haproxy-master
>> process (which we currently don't have), but as far as I can tell from 
>> the
>> output of `lsof` the haproxy-master process doesn't even hold any FDs
>> anymore. Will this setup currently work with your patches at all? Do I 
>> need
>> to add a stats socket to the master process? Or would this require a list
>> of stats sockets to be passed, similar 

Re: [RFC][PATCHES] seamless reload

[Olivier Houchard]

On Thu, Apr 13, 2017 at 03:06:47PM +0200, Conrad Hoffmann wrote:
> 
> 
> On 04/13/2017 02:28 PM, Olivier Houchard wrote:
> > On Thu, Apr 13, 2017 at 12:59:38PM +0200, Conrad Hoffmann wrote:
> >> On 04/13/2017 11:31 AM, Olivier Houchard wrote:
> >>> On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
>  Hi Olivier,
> 
>  On 04/12/2017 06:09 PM, Olivier Houchard wrote:
> > On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
> >> On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
> >>> Hi again,
> >>>
> >>> so I tried to get this to work, but didn't manage yet. I also don't 
> >>> quite
> >>> understand how this is supposed to work. The first haproxy process is
> >>> started _without_ the -x option, is that correct? Where does that 
> >>> instance
> >>> ever create the socket for transfer to later instances?
> >>>
> >>> I have it working now insofar that on reload, subsequent instances are
> >>> spawned with the -x option, but they'll just complain that they can't 
> >>> get
> >>> anything from the unix socket (because, for all I can tell, it's not
> >>> there?). I also can't see the relevant code path where this socket 
> >>> gets
> >>> created, but I didn't have time to read all of it yet.
> >>>
> >>> Am I doing something wrong? Did anyone get this to work with the
> >>> systemd-wrapper so far?
> >>>
> >>> Also, but this might be a coincidence, my test setup takes a huge
> >>> performance penalty just by applying your patches (without any 
> >>> reloading
> >>> whatsoever). Did this happen to anybody else? I'll send some numbers 
> >>> and
> >>> more details tomorrow.
> >>>
> >>
> >> Ok I can confirm the performance issues, I'm investigating.
> >>
> >
> > Found it, I was messing with SO_LINGER when I shouldn't have been.
> 
>  
> 
>  thanks a lot, I can confirm that the performance regression seems to be 
>  gone!
> 
>  I am still having the other (conceptual) problem, though. Sorry if this 
>  is
>  just me holding it wrong or something, it's been a while since I dug
>  through the internals of haproxy.
> 
>  So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
>  which in turn starts haproxy in daemon mode, giving us a process tree 
>  like
>  this (path and file names shortened for brevity):
> 
>  \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
>  \_ /u/s/haproxy-master
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>  \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> 
>  Now, in our config file, we have something like this:
> 
>  # expose admin socket for each process
>    stats socket ${STATS_ADDR}   level admin process 1
>    stats socket ${STATS_ADDR}-2 level admin process 2
>    stats socket ${STATS_ADDR}-3 level admin process 3
>    stats socket ${STATS_ADDR}-4 level admin process 4
>    stats socket ${STATS_ADDR}-5 level admin process 5
>    stats socket ${STATS_ADDR}-6 level admin process 6
>    stats socket ${STATS_ADDR}-7 level admin process 7
>    stats socket ${STATS_ADDR}-8 level admin process 8
>    stats socket ${STATS_ADDR}-9 level admin process 9
>    stats socket ${STATS_ADDR}-10 level admin process 10
>    stats socket ${STATS_ADDR}-11 level admin process 11
>    stats socket ${STATS_ADDR}-12 level admin process 12
> 
>  Basically, we have a dedicate admin socket for each ("real") process, as 
>  we
>  need to be able to talk to each process individually. So I was wondering:
>  which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
>  thought it would have to be a special stats socket in the haproxy-master
>  process (which we currently don't have), but as far as I can tell from 
>  the
>  output of `lsof` the haproxy-master process doesn't even hold any FDs
>  anymore. Will this setup currently work with your patches at all? Do I 
>  need
>  to add a stats socket to the master process? Or would this require a list
>  of stats sockets to be passed, similar to the list of PIDs that gets 
>  passed
>  

Re: Propagating agent-check weight change to tracking servers

[Willy Tarreau]

Hi again Michal,

So in the end I already had to revert your latest patch, I should have
been more careful before merging it.

> We need some CI (even if they will only build haproxy) and IMHO people with
> @haproxy.com mails should test their code before posting and merging :(

Thus please let me reuse your own words above :

  You need some CI, and IMHO people with @allegrogroup.com mails should
  test their code before posting.

but I won't generalize and as I previously said it's development so we
are allowed to break a bit for the sake of trying to make something better,
so case closed.

The problem is immediately spotted in configs like this one :

  global
stats timeout 1h
stats socket /var/run/haproxy.sock level admin mode 600

  defaults
maxconn 100
log 127.0.0.1 local0
option log-health-checks
mode http
timeout client 3s
timeout server 1s
timeout connect 10s
default-server maxconn 50 weight 100

  listen main
bind :8000
stats uri /stat
use_backend customer1 if { req.hdr(host) -i customer1 }
use_backend customer2 if { req.hdr(host) -i customer2 }
use_backend customer3 if { req.hdr(host) -i customer3 }

  backend servers
server s1 127.0.0.1:8001 check inter 1s

  backend customer1
balance uri
hash-type consistent
server s1 127.0.0.1:8001 track servers/s1

  backend customer2
balance uri
server s1 127.0.0.1:8001 track servers/s1

  backend customer3
balance uri
hash-type consistent
server s1 127.0.0.1:8001 track servers/s1

There are 3 backends, one per customer. Two customers use a consistent
hash on the URI while the other one uses a standard hash (map-based).
But all point to the same server, it's just a matter of choice. In fact
an even more common setup with reverse caches looks like this when
users want to use one farm under moderate load and another one under
high load :

   backend leastconn
   balance leastconn
   server s1 127.0.0.1:8001 track cache/s1
   server s2 127.0.0.2:8001 track cache/s2
   server s3 127.0.0.3:8001 track cache/s3

   backend cache
   balance uri
   server s1 127.0.0.1:8001 check
   server s2 127.0.0.2:8001 check
   server s3 127.0.0.3:8001 check

The problem faced here is when a non-integral weight change happens, such
as "50%". Since it can only be applied to backends using a dynamic LB algo,
it will be rejected on others. In the first example above, doing so will
lead to server "s1" in farms "servers" and "customer3" to turn to 50%,
farm "customer2" to generate an error and to abort the processing, and
farm "customer1" not to be changed despite being dynamic thus compatible.

At the very least it's very important that the change remains consistent
across multiple similar farms. Having both customer1 and customer3 identical
and tracking "servers" with different states after a change is not acceptable.

Now what's the best approach here ? I don't really know. We could refuse
to apply the change at all and roll everything back, but that means that
you are supposed to save the respective servers weights in order to restore
them. And it also means that having one new farm tracking a central one and
making use of a non-compatible balance algorithm could prevent all the other
ones from adjusting their weights. Or we can decide that after all, a change
performed to a map-based farm normally only triggers an error and is ignored,
so probably we could simply report the first error, continue, then report the
number of errors at the end of the operation and the rate of success.

Still another problem will remain :

  defaults
balance uri

  backend servers
server s1 127.0.0.1:8001 check inter 1s

  backend customer1
hash-type consistent
server s1 127.0.0.1:8001 track servers/s1

  backend customer2
hash-type consistent
server s1 127.0.0.1:8001 track servers/s1

  backend customer3
hash-type consistent
server s1 127.0.0.1:8001 track servers/s1

This one will always fail to use non-integral weigths because of
the farm receiving the order which itself doesn't use a dynamic
algorithm, and will not be propagated. We could decide that we can
ignore the problem, but then it will render this one inconsistent :

  defaults
balance uri

  backend servers
server s1 127.0.0.1:8001 check inter 1s

  backend customer1
server s1 127.0.0.1:8001 track servers/s1

  backend customer2
hash-type consistent
server s1 127.0.0.1:8001 track customer2/s1

where one could expect that a dynamic backend tracking a static one
would always stay in sync with it, but that would not be true anymore.

So for now I think this requires more thinking, probable a specific server
option like "track-weight" or something like this to let the user decide
whether or not the weights should be 

Re: [RFC][PATCHES] seamless reload

[Conrad Hoffmann]

On 04/13/2017 02:28 PM, Olivier Houchard wrote:
> On Thu, Apr 13, 2017 at 12:59:38PM +0200, Conrad Hoffmann wrote:
>> On 04/13/2017 11:31 AM, Olivier Houchard wrote:
>>> On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
 Hi Olivier,

 On 04/12/2017 06:09 PM, Olivier Houchard wrote:
> On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
>> On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
>>> Hi again,
>>>
>>> so I tried to get this to work, but didn't manage yet. I also don't 
>>> quite
>>> understand how this is supposed to work. The first haproxy process is
>>> started _without_ the -x option, is that correct? Where does that 
>>> instance
>>> ever create the socket for transfer to later instances?
>>>
>>> I have it working now insofar that on reload, subsequent instances are
>>> spawned with the -x option, but they'll just complain that they can't 
>>> get
>>> anything from the unix socket (because, for all I can tell, it's not
>>> there?). I also can't see the relevant code path where this socket gets
>>> created, but I didn't have time to read all of it yet.
>>>
>>> Am I doing something wrong? Did anyone get this to work with the
>>> systemd-wrapper so far?
>>>
>>> Also, but this might be a coincidence, my test setup takes a huge
>>> performance penalty just by applying your patches (without any reloading
>>> whatsoever). Did this happen to anybody else? I'll send some numbers and
>>> more details tomorrow.
>>>
>>
>> Ok I can confirm the performance issues, I'm investigating.
>>
>
> Found it, I was messing with SO_LINGER when I shouldn't have been.

 

 thanks a lot, I can confirm that the performance regression seems to be 
 gone!

 I am still having the other (conceptual) problem, though. Sorry if this is
 just me holding it wrong or something, it's been a while since I dug
 through the internals of haproxy.

 So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
 which in turn starts haproxy in daemon mode, giving us a process tree like
 this (path and file names shortened for brevity):

 \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
 \_ /u/s/haproxy-master
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
 \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds

 Now, in our config file, we have something like this:

 # expose admin socket for each process
   stats socket ${STATS_ADDR}   level admin process 1
   stats socket ${STATS_ADDR}-2 level admin process 2
   stats socket ${STATS_ADDR}-3 level admin process 3
   stats socket ${STATS_ADDR}-4 level admin process 4
   stats socket ${STATS_ADDR}-5 level admin process 5
   stats socket ${STATS_ADDR}-6 level admin process 6
   stats socket ${STATS_ADDR}-7 level admin process 7
   stats socket ${STATS_ADDR}-8 level admin process 8
   stats socket ${STATS_ADDR}-9 level admin process 9
   stats socket ${STATS_ADDR}-10 level admin process 10
   stats socket ${STATS_ADDR}-11 level admin process 11
   stats socket ${STATS_ADDR}-12 level admin process 12

 Basically, we have a dedicate admin socket for each ("real") process, as we
 need to be able to talk to each process individually. So I was wondering:
 which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
 thought it would have to be a special stats socket in the haproxy-master
 process (which we currently don't have), but as far as I can tell from the
 output of `lsof` the haproxy-master process doesn't even hold any FDs
 anymore. Will this setup currently work with your patches at all? Do I need
 to add a stats socket to the master process? Or would this require a list
 of stats sockets to be passed, similar to the list of PIDs that gets passed
 to new haproxy instances, so that each process can talk to the one from
 which it is taking over the socket(s)? In case I need a stats socket for
 the master process, what would be the directive to create it?

>>>
>>> Hi Conrad,
>>>
>>> Any of those sockets will do. Each process are made to keep all the 
>>> listening 

Re: [RFC][PATCHES] seamless reload

[Olivier Houchard]

On Thu, Apr 13, 2017 at 12:59:38PM +0200, Conrad Hoffmann wrote:
> On 04/13/2017 11:31 AM, Olivier Houchard wrote:
> > On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
> >> Hi Olivier,
> >>
> >> On 04/12/2017 06:09 PM, Olivier Houchard wrote:
> >>> On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
>  On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
> > Hi again,
> >
> > so I tried to get this to work, but didn't manage yet. I also don't 
> > quite
> > understand how this is supposed to work. The first haproxy process is
> > started _without_ the -x option, is that correct? Where does that 
> > instance
> > ever create the socket for transfer to later instances?
> >
> > I have it working now insofar that on reload, subsequent instances are
> > spawned with the -x option, but they'll just complain that they can't 
> > get
> > anything from the unix socket (because, for all I can tell, it's not
> > there?). I also can't see the relevant code path where this socket gets
> > created, but I didn't have time to read all of it yet.
> >
> > Am I doing something wrong? Did anyone get this to work with the
> > systemd-wrapper so far?
> >
> > Also, but this might be a coincidence, my test setup takes a huge
> > performance penalty just by applying your patches (without any reloading
> > whatsoever). Did this happen to anybody else? I'll send some numbers and
> > more details tomorrow.
> >
> 
>  Ok I can confirm the performance issues, I'm investigating.
> 
> >>>
> >>> Found it, I was messing with SO_LINGER when I shouldn't have been.
> >>
> >> 
> >>
> >> thanks a lot, I can confirm that the performance regression seems to be 
> >> gone!
> >>
> >> I am still having the other (conceptual) problem, though. Sorry if this is
> >> just me holding it wrong or something, it's been a while since I dug
> >> through the internals of haproxy.
> >>
> >> So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
> >> which in turn starts haproxy in daemon mode, giving us a process tree like
> >> this (path and file names shortened for brevity):
> >>
> >> \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
> >> \_ /u/s/haproxy-master
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> >>
> >> Now, in our config file, we have something like this:
> >>
> >> # expose admin socket for each process
> >>   stats socket ${STATS_ADDR}   level admin process 1
> >>   stats socket ${STATS_ADDR}-2 level admin process 2
> >>   stats socket ${STATS_ADDR}-3 level admin process 3
> >>   stats socket ${STATS_ADDR}-4 level admin process 4
> >>   stats socket ${STATS_ADDR}-5 level admin process 5
> >>   stats socket ${STATS_ADDR}-6 level admin process 6
> >>   stats socket ${STATS_ADDR}-7 level admin process 7
> >>   stats socket ${STATS_ADDR}-8 level admin process 8
> >>   stats socket ${STATS_ADDR}-9 level admin process 9
> >>   stats socket ${STATS_ADDR}-10 level admin process 10
> >>   stats socket ${STATS_ADDR}-11 level admin process 11
> >>   stats socket ${STATS_ADDR}-12 level admin process 12
> >>
> >> Basically, we have a dedicate admin socket for each ("real") process, as we
> >> need to be able to talk to each process individually. So I was wondering:
> >> which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
> >> thought it would have to be a special stats socket in the haproxy-master
> >> process (which we currently don't have), but as far as I can tell from the
> >> output of `lsof` the haproxy-master process doesn't even hold any FDs
> >> anymore. Will this setup currently work with your patches at all? Do I need
> >> to add a stats socket to the master process? Or would this require a list
> >> of stats sockets to be passed, similar to the list of PIDs that gets passed
> >> to new haproxy instances, so that each process can talk to the one from
> >> which it is taking over the socket(s)? In case I need a stats socket for
> >> the master process, what would be the directive to create it?
> >>
> > 
> > Hi Conrad,
> > 
> > Any of those sockets will do. Each process are made to keep all the 
> > listening sockets opened, even if the proxy is not bound to that 

Re: Propagating agent-check weight change to tracking servers

[Frederic Lecaille]

Hello Michal,

On 04/11/2017 04:41 PM, Michał wrote:

Hello Willy,

So I'm fighting with dba97077 made by Frédéric Lécaille - it broke many
things.


This patch broke haproxy non-transparent builds. Thanks to Steven 
Davidovitz, Pavlos Parissis and David Carlier for having promptly helped 
in fixing this.


Excepted this building issue, AFAIK this patch may break only server  or 
default server 'source' setting parsing. How much other things did it break?


Do not forgive that as far as your configuration files do not use any 
'default-server' line with new supported settings (I agree they are 
numerous), they should be parsed as before.


So, if you want to have more chances not to be impacted by my 
"default-server patches", please do not use any 'default-server' new 
supported setting as a first workaround, or no 'default-server' line at 
all as a second workaround. This should help you to continue and develop 
your features.



E.g. you can't use "source", because that patch broke it. I'm curious how
many other stuff got broken with those patches around default-server.



[snipped rude/useless/unproductive published anonymous comments, 
especially towards my colleagues]




In attachment there is patch fixed after your (Willy) review. Sorry for
loop,
I was focused on fixing all those problems with Frédérics patch I just
didn't
think how to replace do..while (which obviously works) with this cleaner
version - thanks for this. The patch got even simpler.


As Willy wrote before, please feel free to contact me to fix asap any 
issue I alone am responsible. I am keeping an eye on HAproxy ML, and I 
would still be glad to help you and consequently any other haproxy users.


Regards,
Fred.

Re: ModSecurity: First integration patches

[Christopher Faulet]

Le 13/04/2017 à 12:53, Thierry Fournier a écrit :



On 13 Apr 2017, at 12:28, Willy Tarreau  wrote:

On Thu, Apr 13, 2017 at 12:21:20PM +0200, Thierry Fournier wrote:

.) the patches apply only on haproxy 1.8 because some files does not exists on 
1.7 ( e. g. include/proto/spoe.h )



Ok. I think that SPOE was introduced in 1.7, obviously I'm wrong.


No, it was introduced in 1.7 but there were some improvements later
(like pipelining etc).

(...)

.) How can the rule-set be reloaded? stop & start || gracefully?



I do not process this part. Today, you must stop and start the process. The 
graceful doesn't exists.
I guess than the graceful can be implemented easily. You can ensure the 
availability of the
SPOA Modsec using the properties of the HAProxy backend.


Actually that's a very good point. I think it would even be possible to
ensure a graceful shutdown using disable-on-404 or using an agent so
that you can roll the restart over multiple WAF nodes.



Interesting. I think about a system which (on SPOA side) stop listeners
and wait for the end of processing current requests. By this way, the SPOA
doesn’t accept requests, and HAProxy send requests on the other process.
Another way is using the CLI and set one spoa/modsec in graceful mode.

Adding a special check is the best way, but the daemon speaks SPOP and not
HTTP. Maybe a thread which listen on specific port dedicated to this
function ? Or improving the SPOP for asking graceful mode in the agent-hello
response message ? (it seems that haproxy send periodically haproxy-hello
messages, but maybe I’m wrong)



The hello-handshake is done only once, when a new connection with a SPOA 
is opened. But we can improve the SPOP by adding a new frame type to 
handle admin tasks (like graceful stop). This way, for a specific 
connection, it would be possible to wait for last ACK frames without 
sending new frames to the SPOA. Then stopping the SPOA listeners to let 
the SPOP health check failed should do the trick, I guess.


--
Christopher Faulet

Re: [RFC][PATCHES] seamless reload

[Conrad Hoffmann]

On 04/13/2017 11:31 AM, Olivier Houchard wrote:
> On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
>> Hi Olivier,
>>
>> On 04/12/2017 06:09 PM, Olivier Houchard wrote:
>>> On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
 On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
> Hi again,
>
> so I tried to get this to work, but didn't manage yet. I also don't quite
> understand how this is supposed to work. The first haproxy process is
> started _without_ the -x option, is that correct? Where does that instance
> ever create the socket for transfer to later instances?
>
> I have it working now insofar that on reload, subsequent instances are
> spawned with the -x option, but they'll just complain that they can't get
> anything from the unix socket (because, for all I can tell, it's not
> there?). I also can't see the relevant code path where this socket gets
> created, but I didn't have time to read all of it yet.
>
> Am I doing something wrong? Did anyone get this to work with the
> systemd-wrapper so far?
>
> Also, but this might be a coincidence, my test setup takes a huge
> performance penalty just by applying your patches (without any reloading
> whatsoever). Did this happen to anybody else? I'll send some numbers and
> more details tomorrow.
>

 Ok I can confirm the performance issues, I'm investigating.

>>>
>>> Found it, I was messing with SO_LINGER when I shouldn't have been.
>>
>> 
>>
>> thanks a lot, I can confirm that the performance regression seems to be gone!
>>
>> I am still having the other (conceptual) problem, though. Sorry if this is
>> just me holding it wrong or something, it's been a while since I dug
>> through the internals of haproxy.
>>
>> So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
>> which in turn starts haproxy in daemon mode, giving us a process tree like
>> this (path and file names shortened for brevity):
>>
>> \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
>> \_ /u/s/haproxy-master
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
>>
>> Now, in our config file, we have something like this:
>>
>> # expose admin socket for each process
>>   stats socket ${STATS_ADDR}   level admin process 1
>>   stats socket ${STATS_ADDR}-2 level admin process 2
>>   stats socket ${STATS_ADDR}-3 level admin process 3
>>   stats socket ${STATS_ADDR}-4 level admin process 4
>>   stats socket ${STATS_ADDR}-5 level admin process 5
>>   stats socket ${STATS_ADDR}-6 level admin process 6
>>   stats socket ${STATS_ADDR}-7 level admin process 7
>>   stats socket ${STATS_ADDR}-8 level admin process 8
>>   stats socket ${STATS_ADDR}-9 level admin process 9
>>   stats socket ${STATS_ADDR}-10 level admin process 10
>>   stats socket ${STATS_ADDR}-11 level admin process 11
>>   stats socket ${STATS_ADDR}-12 level admin process 12
>>
>> Basically, we have a dedicate admin socket for each ("real") process, as we
>> need to be able to talk to each process individually. So I was wondering:
>> which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
>> thought it would have to be a special stats socket in the haproxy-master
>> process (which we currently don't have), but as far as I can tell from the
>> output of `lsof` the haproxy-master process doesn't even hold any FDs
>> anymore. Will this setup currently work with your patches at all? Do I need
>> to add a stats socket to the master process? Or would this require a list
>> of stats sockets to be passed, similar to the list of PIDs that gets passed
>> to new haproxy instances, so that each process can talk to the one from
>> which it is taking over the socket(s)? In case I need a stats socket for
>> the master process, what would be the directive to create it?
>>
> 
> Hi Conrad,
> 
> Any of those sockets will do. Each process are made to keep all the 
> listening sockets opened, even if the proxy is not bound to that specific
> process, justly so that it can be transferred via the unix socket.
> 
> Regards,
> 
> Olivier


Thanks, I am finally starting to understand, but I think there still might
be a problem. I didn't see that initially, but when I use one of the
processes existing admin sockets it 

Re: ModSecurity: First integration patches

[Thierry Fournier]

> On 13 Apr 2017, at 12:28, Willy Tarreau  wrote:
> 
> On Thu, Apr 13, 2017 at 12:21:20PM +0200, Thierry Fournier wrote:
>>> .) the patches apply only on haproxy 1.8 because some files does not exists 
>>> on 1.7 ( e. g. include/proto/spoe.h )
>> 
>> 
>> Ok. I think that SPOE was introduced in 1.7, obviously I'm wrong.
> 
> No, it was introduced in 1.7 but there were some improvements later
> (like pipelining etc).
> 
> (...)
>>> .) How can the rule-set be reloaded? stop & start || gracefully?
>> 
>> 
>> I do not process this part. Today, you must stop and start the process. The 
>> graceful doesn't exists.
>> I guess than the graceful can be implemented easily. You can ensure the 
>> availability of the
>> SPOA Modsec using the properties of the HAProxy backend.
> 
> Actually that's a very good point. I think it would even be possible to
> ensure a graceful shutdown using disable-on-404 or using an agent so
> that you can roll the restart over multiple WAF nodes.


Interesting. I think about a system which (on SPOA side) stop listeners
and wait for the end of processing current requests. By this way, the SPOA
doesn’t accept requests, and HAProxy send requests on the other process.
Another way is using the CLI and set one spoa/modsec in graceful mode.

Adding a special check is the best way, but the daemon speaks SPOP and not
HTTP. Maybe a thread which listen on specific port dedicated to this
function ? Or improving the SPOP for asking graceful mode in the agent-hello
response message ? (it seems that haproxy send periodically haproxy-hello
messages, but maybe I’m wrong)

Thierry


> Willy

Re: Lua memory allocator

[Thierry Fournier]

> On 12 Apr 2017, at 23:30, Willy Tarreau  wrote:
> 
> Thierry,
> 
> while instrumenting my malloc/free functions to debug a problem, I was
> hit by a malloc/realloc inconsistency in the Lua allocator. The problem
> is that luaL_newstate() uses malloc() to create its first objects and
> only after this one we change the allocator to use ours. Thus on the
> first realloc() call it fails because it tries to reallocate using one
> function something allocated differently earlier.
> 
> I found some info regarding the fact that instead it was possible to
> use lua_newstate() and pass it the allocator to use. So that's what I
> did and it solve the problem for me.
> 
> I think that it results in more accurately accounting the memory in use
> by the Lua stack since even the very first malloc is counted now. But
> could you take a quick look to ensure I didn't overlook anything ? I'm
> attaching the patch, if you're fine with it I can merge it.


Hi,

Good catch. I read the code of the Lua function luaL_newstate, and I
approve your change because this function dos exactly the same job, but
with a libc memory allocator. Note that a few lines after after your patch
(about 15 lines), I call the function “lua_setallocf()” which set again
the memory allocator. I think that this line becomes useless and it will
be better to remove it.

Thierry


> Thanks,
> Willy
> <0001-MINOR-lua-ensure-the-memory-allocator-is-used-all-th.patch>

Re: ModSecurity: First integration patches

[Willy Tarreau]

On Thu, Apr 13, 2017 at 12:21:20PM +0200, Thierry Fournier wrote:
> > .) the patches apply only on haproxy 1.8 because some files does not exists 
> > on 1.7 ( e. g. include/proto/spoe.h )
> 
> 
> Ok. I think that SPOE was introduced in 1.7, obviously I'm wrong.

No, it was introduced in 1.7 but there were some improvements later
(like pipelining etc).

(...)
> > .) How can the rule-set be reloaded? stop & start || gracefully?
> 
> 
> I do not process this part. Today, you must stop and start the process. The 
> graceful doesn't exists.
> I guess than the graceful can be implemented easily. You can ensure the 
> availability of the
> SPOA Modsec using the properties of the HAProxy backend.

Actually that's a very good point. I think it would even be possible to
ensure a graceful shutdown using disable-on-404 or using an agent so
that you can roll the restart over multiple WAF nodes.

Willy

Re: ModSecurity: First integration patches

[Thierry Fournier]

> On 13 Apr 2017, at 02:06, Aleksandar Lazic  wrote:
> 
> 
> 
> Am 12-04-2017 23:33, schrieb Aleksandar Lazic:
>> Am 12-04-2017 21:28, schrieb thierry.fourn...@arpalert.org:
>>> On Wed, 12 Apr 2017 21:21:58 +0200
>>> Aleksandar Lazic  wrote:
> 
> [snipp]
> 
 Do you have the patches as files where I can download it?
 It's easier for docker to call a 'curl -vLO ...' then to go across a
 mail body ;-)
>>> Not sure to understand. I given the patches as file. Note that I'm
>>> testing new email client. So I put the patches here:
>>> http://www.arpalert.org/0001-BUG-MINOR-change-header-declared-function-to-static-.patch
>>> http://www.arpalert.org/0002-MINOR-Add-binary-encoding-request-sample-fetch.patch
>>> http://www.arpalert.org/0003-MINOR-Add-ModSecurity-wrapper-as-contrib.patch
>> I'm so sorry for the rush. :-(
>> I have seen to late that you have send the patches to the list.
>> Thanks for the links. I will take more care in the future.
> 
> I have now build the haproxy with modsecurity on centos 7.3 ;-)
> 
> I have used this file for modsecurity.
> https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/crs-setup.conf.example
> 
> ###
> /usr/local/bin/modsecurity -f crs-setup.conf.example
> 1492041223.145110 [00] ModSecurity for nginx (STABLE)/2.9.1 
> (http://www.modsecurity.org/) configured.
> 1492041223.145159 [00] ModSecurity: APR compiled version="1.4.8"; loaded 
> version="1.4.8"
> 1492041223.145193 [00] ModSecurity: PCRE compiled version="8.32 "; loaded 
> version="8.32 2012-11-30"
> 1492041223.145197 [00] ModSecurity: LIBXML compiled version="2.9.1"
> 1492041223.145200 [00] ModSecurity: Status engine is currently disabled, 
> enable it by set SecStatusEngine to On.
> 1492041228.152877 [01] 0 clients connected
> 1492041228.153037 [02] 0 clients connected
> 1492041228.153069 [03] 0 clients connected
> ...
> ###
> 
> It was a little bit challenging.
> 
> .) the patches apply only on haproxy 1.8 because some files does not exists 
> on 1.7 ( e. g. include/proto/spoe.h )


Ok. I think that SPOE was introduced in 1.7, obviously I’m wrong.


> git clone http://git.haproxy.org/git/haproxy.git/
> 
> patch -d haproxy -p 1 -i 
> /usr/src/0001-BUG-MINOR-change-header-declared-function-to-static-.patch
> patch -d haproxy -p 1 -i 
> /usr/src/0002-MINOR-Add-binary-encoding-request-sample-fetch.patch
> patch -d haproxy -p 1 -i 
> /usr/src/0003-MINOR-Add-ModSecurity-wrapper-as-contrib.patch
> 
> .) you will need a lot of devel packages inclusive some httpd one.
> 
> yum install -y apr-devel apr-util-devel gcc make libevent-devel libxml2-devel 
> libcurl-devel httpd-devel pcre-devel yajl-devel


Yes Modsecurity is linked designed for apache and needs Apache libraries (APR), 
libevent is for
the SPOA. libcurl and yajl are used for the Modsecurity “mlogc” function.


> .) I will figure out which runtime packages will be necessary.
> .) I have started a Dockerfile which you can find at github.
> 
> https://github.com/git001/haproxy-waf/blob/master/Dockerfile
> 
> Open questions for me.


Note: I swapped the order of your questions


> .) How big can a content be? Where can we define some limits?


ModSecurity analyses an Haproxy buffer. (don’t forget the directive “option 
http-buffer-request”)
For my own usage, the HAProxy buffer are configured as 1MB. When the buffer is 
full or when
the http request is receive, all the data are offloaded towards ModSecurity.


> .) How is the transfer-encoding handled (a. k. a. streaming)?


The stream is not processed, just the first buffer containing the header 
request and a maximum
of the body it is.


> .) How can the rule-set be reloaded? stop & start || gracefully?


I do not process this part. Today, you must stop and start the process. The 
graceful doesn’t exists.
I guess than the graceful can be implemented easily. You can ensure the 
availability of the
SPOA Modsec using the properties of the HAProxy backend.


> Again thanks Thierry for your work this looks very good.


Thanks for testing.

Thierry


> Regards
> Aleks

Suggestion for ACL groups

[Julian Zielke]

Hi,

lately I had to define multiple acls in our pfsense box runnign HaProxy 1.6.x.

The challenge was to configure a frontend with multiple URLs as ACLs and also 
limit IPs to some URLs and some other avaiable to any or a different set of IPs.

Example:

a_url1 --> host match www.mydomain.com
a_url2 --> host match www.myotherdomain.com
a_net1 --> source ip match www.xxx.yyy.zzz
a_net2 --> source ip match aaa.bbb.ccc.ddd

So for every frontend the match syntax would be:

use backend if a_url1 a_net1 || a_url1 a_net2 || a_url2 a_net1 || a_url2_a_net2

Having a one-line directive this rule set with more IPs and/or URLs can be a 
real pita.
So my suggestion would be a group-syntax for ACLs which would be like:

(a_url1 || a_url2 ) (a_net1 || a_net2)

Much more compact and serves the same purpose. Would be nice to see this being 
implemente.
Searching accross Google some ppl already asked for this already on different 
forums.

- Julian

Wichtiger Hinweis: Der Inhalt dieser E-Mail ist vertraulich und ausschlie?lich 
f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene 
Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie 
bitte, dass jede Form der Kenntnisnahme, Ver?ffentlichung, Vervielf?ltigung 
oder Weitergabe des Inhalts dieser E-Mail unzul?ssig ist. Wir bitten Sie, sich 
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. Wir m?chten 
Sie au?erdem darauf hinweisen, dass die Kommunikation per E-Mail ?ber das 
Internet unsicher ist, da f?r unberechtigte Dritte grunds?tzlich die 
M?glichkeit der Kenntnisnahme und Manipulation besteht

Important Note: The information contained in this e-mail is confidential. It is 
intended solely for the addressee. Access to this e-mail by anyone else is 
unauthorized. If you are not the intended recipient, any form of disclosure, 
reproduction, distribution or any action taken or refrained from in reliance on 
it, is prohibited and may be unlawful. Please notify the sender immediately. We 
also would like to inform you that communication via e-mail over the internet 
is insecure because third parties may have the possibility to access and 
manipulate e-mails.

Re: Propagating agent-check weight change to tracking servers

[Willy Tarreau]

Hi Michal,

so I've merged your patch now eventhough I'm still not totally convinced
it's a good idea, I continue to think it will lead to some surprizes.

Regarding your point below :

> E.g. you can't use "source", because that patch broke it. I'm curious how
> many other stuff got broken with those patches around default-server.

For me "source" seems to work fine. Did you at least send Frédéric a
working reproducer for the issue you discovered ? If not, I'm not going
to spend more time trying to guess what problem you may have faced :-/

Regards,
Willy

Re: [RFC][PATCHES] seamless reload

[Olivier Houchard]

On Thu, Apr 13, 2017 at 11:17:45AM +0200, Conrad Hoffmann wrote:
> Hi Olivier,
> 
> On 04/12/2017 06:09 PM, Olivier Houchard wrote:
> > On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
> >> On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
> >>> Hi again,
> >>>
> >>> so I tried to get this to work, but didn't manage yet. I also don't quite
> >>> understand how this is supposed to work. The first haproxy process is
> >>> started _without_ the -x option, is that correct? Where does that instance
> >>> ever create the socket for transfer to later instances?
> >>>
> >>> I have it working now insofar that on reload, subsequent instances are
> >>> spawned with the -x option, but they'll just complain that they can't get
> >>> anything from the unix socket (because, for all I can tell, it's not
> >>> there?). I also can't see the relevant code path where this socket gets
> >>> created, but I didn't have time to read all of it yet.
> >>>
> >>> Am I doing something wrong? Did anyone get this to work with the
> >>> systemd-wrapper so far?
> >>>
> >>> Also, but this might be a coincidence, my test setup takes a huge
> >>> performance penalty just by applying your patches (without any reloading
> >>> whatsoever). Did this happen to anybody else? I'll send some numbers and
> >>> more details tomorrow.
> >>>
> >>
> >> Ok I can confirm the performance issues, I'm investigating.
> >>
> > 
> > Found it, I was messing with SO_LINGER when I shouldn't have been.
> 
> 
> 
> thanks a lot, I can confirm that the performance regression seems to be gone!
> 
> I am still having the other (conceptual) problem, though. Sorry if this is
> just me holding it wrong or something, it's been a while since I dug
> through the internals of haproxy.
> 
> So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
> which in turn starts haproxy in daemon mode, giving us a process tree like
> this (path and file names shortened for brevity):
> 
> \_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
> \_ /u/s/haproxy-master
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> \_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
> 
> Now, in our config file, we have something like this:
> 
> # expose admin socket for each process
>   stats socket ${STATS_ADDR}   level admin process 1
>   stats socket ${STATS_ADDR}-2 level admin process 2
>   stats socket ${STATS_ADDR}-3 level admin process 3
>   stats socket ${STATS_ADDR}-4 level admin process 4
>   stats socket ${STATS_ADDR}-5 level admin process 5
>   stats socket ${STATS_ADDR}-6 level admin process 6
>   stats socket ${STATS_ADDR}-7 level admin process 7
>   stats socket ${STATS_ADDR}-8 level admin process 8
>   stats socket ${STATS_ADDR}-9 level admin process 9
>   stats socket ${STATS_ADDR}-10 level admin process 10
>   stats socket ${STATS_ADDR}-11 level admin process 11
>   stats socket ${STATS_ADDR}-12 level admin process 12
> 
> Basically, we have a dedicate admin socket for each ("real") process, as we
> need to be able to talk to each process individually. So I was wondering:
> which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
> thought it would have to be a special stats socket in the haproxy-master
> process (which we currently don't have), but as far as I can tell from the
> output of `lsof` the haproxy-master process doesn't even hold any FDs
> anymore. Will this setup currently work with your patches at all? Do I need
> to add a stats socket to the master process? Or would this require a list
> of stats sockets to be passed, similar to the list of PIDs that gets passed
> to new haproxy instances, so that each process can talk to the one from
> which it is taking over the socket(s)? In case I need a stats socket for
> the master process, what would be the directive to create it?
> 

Hi Conrad,

Any of those sockets will do. Each process are made to keep all the 
listening sockets opened, even if the proxy is not bound to that specific
process, justly so that it can be transferred via the unix socket.

Regards,

Olivier

Re: [RFC][PATCHES] seamless reload

[Conrad Hoffmann]

Hi Olivier,

On 04/12/2017 06:09 PM, Olivier Houchard wrote:
> On Wed, Apr 12, 2017 at 05:50:54PM +0200, Olivier Houchard wrote:
>> On Wed, Apr 12, 2017 at 05:30:17PM +0200, Conrad Hoffmann wrote:
>>> Hi again,
>>>
>>> so I tried to get this to work, but didn't manage yet. I also don't quite
>>> understand how this is supposed to work. The first haproxy process is
>>> started _without_ the -x option, is that correct? Where does that instance
>>> ever create the socket for transfer to later instances?
>>>
>>> I have it working now insofar that on reload, subsequent instances are
>>> spawned with the -x option, but they'll just complain that they can't get
>>> anything from the unix socket (because, for all I can tell, it's not
>>> there?). I also can't see the relevant code path where this socket gets
>>> created, but I didn't have time to read all of it yet.
>>>
>>> Am I doing something wrong? Did anyone get this to work with the
>>> systemd-wrapper so far?
>>>
>>> Also, but this might be a coincidence, my test setup takes a huge
>>> performance penalty just by applying your patches (without any reloading
>>> whatsoever). Did this happen to anybody else? I'll send some numbers and
>>> more details tomorrow.
>>>
>>
>> Ok I can confirm the performance issues, I'm investigating.
>>
> 
> Found it, I was messing with SO_LINGER when I shouldn't have been.



thanks a lot, I can confirm that the performance regression seems to be gone!

I am still having the other (conceptual) problem, though. Sorry if this is
just me holding it wrong or something, it's been a while since I dug
through the internals of haproxy.

So, as I mentioned before, we use nbproc (12) and the systemd-wrapper,
which in turn starts haproxy in daemon mode, giving us a process tree like
this (path and file names shortened for brevity):

\_ /u/s/haproxy-systemd-wrapper -f ./hap.cfg -p /v/r/hap.pid
\_ /u/s/haproxy-master
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds
\_ /u/s/haproxy -f ./hap.cfg -p /v/r/hap.pid -Ds

Now, in our config file, we have something like this:

# expose admin socket for each process
  stats socket ${STATS_ADDR}   level admin process 1
  stats socket ${STATS_ADDR}-2 level admin process 2
  stats socket ${STATS_ADDR}-3 level admin process 3
  stats socket ${STATS_ADDR}-4 level admin process 4
  stats socket ${STATS_ADDR}-5 level admin process 5
  stats socket ${STATS_ADDR}-6 level admin process 6
  stats socket ${STATS_ADDR}-7 level admin process 7
  stats socket ${STATS_ADDR}-8 level admin process 8
  stats socket ${STATS_ADDR}-9 level admin process 9
  stats socket ${STATS_ADDR}-10 level admin process 10
  stats socket ${STATS_ADDR}-11 level admin process 11
  stats socket ${STATS_ADDR}-12 level admin process 12

Basically, we have a dedicate admin socket for each ("real") process, as we
need to be able to talk to each process individually. So I was wondering:
which admin socket should I pass as HAPROXY_STATS_SOCKET? I initially
thought it would have to be a special stats socket in the haproxy-master
process (which we currently don't have), but as far as I can tell from the
output of `lsof` the haproxy-master process doesn't even hold any FDs
anymore. Will this setup currently work with your patches at all? Do I need
to add a stats socket to the master process? Or would this require a list
of stats sockets to be passed, similar to the list of PIDs that gets passed
to new haproxy instances, so that each process can talk to the one from
which it is taking over the socket(s)? In case I need a stats socket for
the master process, what would be the directive to create it?

Thanks a lot,
Conrad
-- 
Conrad Hoffmann
Traffic Engineer

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany

Managing Director: Alexander Ljung | Incorporated in England & Wales
with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
HRB 110657B

Re: [RFC][PATCHES] seamless reload

[Willy Tarreau]

On Wed, Apr 12, 2017 at 07:41:43PM +0200, Olivier Houchard wrote:
> + if (default_tcp_maxseg == -1) {
> + default_tcp_maxseg = -2;
> + fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
> + if (fd < 0)
> + Warning("Failed to create a temporary socket!\n");
> + else {
> + if (getsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, 
> _tcp_maxseg,
> + _len) == -1)
> + Warning("Failed to get the default value of 
> TCP_MAXSEG\n");

Olivier, you're missing a close(fd) here, it'll leak this fd.

> + }
> + }
> + if (default_tcp6_maxseg == -1) {
> + default_tcp6_maxseg = -2;
> + fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
> + if (fd >= 0) {
> + if (getsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, 
> _tcp6_maxseg,
> + _len) == -1)
> + Warning("Failed ot get the default value of 
> TCP_MAXSEG for IPv6\n");
> + close(fd);
> + }
> + }
> +#endif
> +
>  
(...)

> + getsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, , );
> + if (tmpmaxseg != defaultmss &&
> + setsockopt(fd, IPPROTO_TCP, TCP_MAXSEG,
> + , sizeof(defaultmss)) == -1) {

Please fix the alignment for the argument here, it's a bit confusing :-)

Otherwise looks good. I think it was a good idea to create temporary
sockets to retrieve some default settings. That may be something we
could generalize to guess other parameters or capabilities if needed
in the future. For example we could use this to detect whether or not
IPv6 is supported and emit errors only once instead of every bind line.

Another use case is to always know the MSS applied to a listening socket
in order to automatically adjust the SSL maxrecord instead of assuming
1460 by default. Over time we might find other use cases.

Cheers,
Willy