date:20151030

On Thu, Oct 29, 2015 at 10:57:47AM +, ??? wrote:
> I have this in config file
> 
> listen railgun
> option  transparent
> bind *:5000 transparent
> server main *
> source *
> tcp-request content lua.test
> tcp-request content reject if LOCALHOST
> 
> and this in .lua
> 
> core.register_action("test", { "tcp-req", "http-req" }, function(txn)
>txn:Info("test")
>txn:set_mark(0x10)
>txn:set_tos(0x10)
> end)
> 
> then run
> 
> sudo haproxy -f /etc/haproxy/haproxy.cfg -d
> 
> and it successfully prints "test" on each connection, but i see every
> packet TOS is 0, not 0x10. same for mark.

On which side ? set_tos and set_mark affect the front connection (with the
client).

Can you check if the equivalent TCP actions work
(tcp-request content set-mark ...) ?

Regards,
Willy

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

On Fri, Oct 30, 2015 at 08:04:48AM +0100, Vincent Bernat wrote:
>  ??? 30 octobre 2015 00:34 -0400, Chris Riley  :
> 
> > The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS
> > 6.4.
> 
> With this version of the kernel, the previous instance of HAProxy has to
> release the port before the new one can bind. It seems that in your
> case, this doesn't happen. Nothing suspicious in the logs of the
> previous instance?

It would be nice to ensure the process is reloaded with appropriate
permissions. The new process indeed needs to send a signal to the old
process, and bind to the ports. If any of these operations fail, it will
not be able to start.

Willy

Re: lua TXN.set_tos not work

On Fri, Oct 30, 2015 at 08:16:07AM +, ??? wrote:
> ohh.. i want to modify backend side... how to to it?

It was not implemented. I noticed that the choice of action names was
rather poor because it's confusing, no side is indicated. I think in
1.7 we'll have to rename some actions to make them more obvious, these
ones included.

It will be a little more difficult to implement on the backend side
because the decision is taken before the connection is established
so we have to store that decision somewhere. On the frontend side it
was easy, we just find the connection's fd and perform the action
immediately.

Willy

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

 ❦ 30 octobre 2015 00:34 -0400, Chris Riley  :

> The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS
> 6.4.

With this version of the kernel, the previous instance of HAProxy has to
release the port before the new one can bind. It seems that in your
case, this doesn't happen. Nothing suspicious in the logs of the
previous instance?
-- 
Let us endeavor so to live that when we come to die even the undertaker will be
sorry.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: lua TXN.set_tos not work

2015-10-30 Thread 神楽坂玲奈

ohh.. i want to modify backend side... how to to it?

Willy Tarreau 于2015年10月30日周五 下午3:17写道：

> On Thu, Oct 29, 2015 at 10:57:47AM +, ??? wrote:
> > I have this in config file
> >
> > listen railgun
> > option  transparent
> > bind *:5000 transparent
> > server main *
> > source *
> > tcp-request content lua.test
> > tcp-request content reject if LOCALHOST
> >
> > and this in .lua
> >
> > core.register_action("test", { "tcp-req", "http-req" }, function(txn)
> >txn:Info("test")
> >txn:set_mark(0x10)
> >txn:set_tos(0x10)
> > end)
> >
> > then run
> >
> > sudo haproxy -f /etc/haproxy/haproxy.cfg -d
> >
> > and it successfully prints "test" on each connection, but i see every
> > packet TOS is 0, not 0x10. same for mark.
>
> On which side ? set_tos and set_mark affect the front connection (with the
> client).
>
> Can you check if the equivalent TCP actions work
> (tcp-request content set-mark ...) ?
>
> Regards,
> Willy
>
>

Re: Need some help configuring backend health checks

On 30/10/2015 4:48 PM, "Daren Sefcik"  wrote:
>
> So I think those links were the right idea and I have been trying
different configurations but am not quite there and am hoping somebody can
offer a bit more guidance.
>
> So when I telnet to the icap server I type in the OPTIONS line followed
by (2) return key presses and then it returns the ICAP text, below is my
telent session output
>
> ===
>
> $ telnet 10.1.4.153 1344
> Trying 10.1.4.153...
> Connected to 10.1.4.153.
> Escape character is '^]'.
> OPTIONS icap://127.0.0.1:1344/respmod ICAP/1.0
>
> ICAP/1.0 200 OK
> ISTAG: "5BDEEEA9-12E4-2"
> Service: Diladele Web Safety 4.2.0.CBF4
> Service-ID: qlproxy
> Methods: RESPMOD
> Options-TTL: 3600
> Max-Connections: 15000
> Allow: 204
> Preview: 4096
> Transfer-Preview: *
> Encapsulated: null-body=0
> Connection: close
>
> 
>
>
> Here is what I have tried in the backend configurations
>
> option tcp-check
> tcp-check send OPTIONS\ icap\:\/\/127\.0\.0\.1\:1344\/respmod\
ICAP\/1\.0\r\n\
> tcp-check send \r\n
> tcp-check expect string ICAP\/1\.0\ 200\ OK
>
>
> but it is still not working, I suspect I need to use some type of regex
or such. Hoping somebody can help me along with this.
>
> TIA..
>
>
> On Mon, Oct 19, 2015 at 7:42 AM, Daren Sefcik 
wrote:
>>
>> Thanks Jarno, I am still not sure how I can apply this to each server
using a different port but will poke around at it and see if I can figure
it out.
>>
>> On Mon, Oct 19, 2015 at 1:04 AM, Jarno Huuskonen 
wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Oct 18, Daren Sefcik wrote:
>>> > I have an ICAP server backend with servers that each listen on
different
>>> > ports, can anyone offer some advice on how to configure health checks
for
>>> > it? I am currently using basic but that really doesn't help if the
service
>>> > is not responding.
>>> >
>>> > Here is my haproxy config for the backend:
>>> >
>>> > backend HTPL_CONT_FILTER_tcp_ipvANY
>>> > mode tcp
>>> > balance roundrobin
>>> > timeout connect 5
>>> > timeout server 5
>>> > retries 3
>>> > server HTPL-WEB-01_10.1.4.153 10.1.4.153:1344 check inter 5000
weight 200
>>> > maxconn 200 fastinter 1000 fall 5
>>> > server HTPL-WEB-02_10.1.4.154 10.1.4.154:1344 check inter 5000
weight 200
>>> > maxconn 200 fastinter 1000 fall 5
>>> > server HTPL-WEB-02_10.1.4.155_01 10.1.4.155:8102 check inter 5000
weight
>>> > 200 maxconn 200 fastinter 1000 fall 5
>>> > server HTPL-WEB-02_10.1.4.155_02 10.1.4.155:8202 check inter 5000
weight
>>> > 200 maxconn 200 fastinter 1000 fall 5
>>>
>>> Do the icap servers (squid+diladele?) respond to something like this:
>>> https://support.symantec.com/en_US/article.TECH220980.html
>>> or https://exchange.icinga.org/oldmonex/1733-check_icap.pl/check_icap.pl
>>>
>>> Maybe you can use tcp-check to send icap request and look for
>>> "ICAP/1.0 200" response:
>>>
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#tcp-check%20connect
>>> http://blog.haproxy.com/2014/01/02/haproxy-advanced-redis-health-check/
>>>
>>> -Jarno
>>>
>>> --
>>> Jarno Huuskonen
>>
>>
>
Since your telnet session is on port 1344, maybe

tcp-check connect port 1344

before the send command.

Re: [LUA] Lua advanced documentation

Hi guys,

On Thu, Oct 29, 2015 at 01:22:31PM +0100, Thierry FOURNIER wrote:
> Ok, this is a good comment ! My explaination was not clear. I will
> improve the explaination. For your information, the function associated
> with "core.register_task()" is executed once, if you want that the
> function does anything each period of time, you can use a core.sleep().
> 
> I will add an example.

Thierry, your doc is really useful. When you consider it in good
enough shape, please submit it, we'll happily integrate it into
1.6-stable as well. Don't be too perfectionnist, once it starts
to become useful and helpful, it's worth merging it and it will
evolve there.

Willy

HAProxy 1.6 in Fedora/Rawhide

2015-10-30 Thread Ryan O'Hara


I've build HAProxy 1.6.1 for Rawhide (Fedora 24), but I'm not
currently planning to add this to Fedora 23. If there is enough
interest, I will gladly provide HAProxy 1.6.1 packages for Fedora 23,
but they will most likely not be pushed into the updates
repository. Long story there.

Anyway, just wanted to let you know that builds are working and if
there are any Fedora users that would like these packages, just send
me an email. Cheers!

Ryan

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Vincent,

> SigIgn is correct (SIGPIPE) is ignored. However, SigBlk seems
> incorrect. HAProxy only blocks signals when dequeuing them. However, > no 
> signal
is pending either, so they should be delivered? Maybe it was
> bad luck? If you try again, does SigBlk become 0?

No matter how many times I send signals to this process, SigBlk remains as
fffe7bfa7a26.

I did find something that seems odd though when I was looking at the file
descriptors that this PID has open.

When I run lsof I see this (output filtered for brevity, excludes linked
libraries):

COMMAND PIDUSER   FD  TYPE DEVICE SIZE/OFF
NODE NAME
haproxy   11537 haproxy0u 0,90
5350 anon_inode
haproxy   11537 haproxy4u unix 0x88023306d200  0t0
126464 /tmp/haproxy.sock.11536.tmp
haproxy   11537 haproxy5u IPv4 126465  0t0
 TCP 192.168.10.15:http (LISTEN)
haproxy   11537 haproxy6u IPv4 126466  0t0
 UDP *:58171
haproxy   11537 haproxy7u IPv4 126467  0t0
 TCP 192.168.200.100:http (LISTEN)
haproxy   11537 haproxy8u IPv4 126468  0t0
 TCP 192.168.200.120:http (LISTEN)
haproxy   11537 haproxy9u IPv4 126469  0t0
 TCP 192.168.200.110:http (LISTEN)

The first odd thing is that /tmp/haproxy.sock.11536.tmp does not exist. The
socket file that stats socket uses is defined as /tmp/haproxy.sock in
haproxy.cfg. And it's either odd or a coincidence that the number in the
filename is 1 digit lower than the PID.

After running lsof I took a look at /proc/11537/fd

ls -l /proc/11537/fd
total 0
lrwx-- 1 root root 64 Oct 30 15:29 0 -> anon_inode:[eventpoll]
lrwx-- 1 root root 64 Oct 30 15:29 4 -> socket:[126464]
lrwx-- 1 root root 64 Oct 30 15:29 5 -> socket:[126465]
lrwx-- 1 root root 64 Oct 30 15:29 6 -> socket:[126466]
lrwx-- 1 root root 64 Oct 30 15:29 7 -> socket:[126467]
lrwx-- 1 root root 64 Oct 30 15:29 8 -> socket:[126468]
lrwx-- 1 root root 64 Oct 30 15:29 9 -> socket:[126469]

It won't show here but all of those symlinks are non-existent (flashing
red). And each one of those symlinks corresponds to FD listed in the output
of lsof that shows haproxy actively listening on those sockets. (?) And if
I connect to any of those IPs:ports they pass traffic.

In looking at tcp_bind_listener() in proto_tcp.c (comment on line 782) it
indicates that the desired behavior is to reuse file descriptors instead of
creating a new socket. Would these orphaned file descriptors indicate that
a new socket was created instead of the file descriptors being reused? I'm
wondering if that is the case due to the behavior I saw with kernel 2.6 and
the "cannot bind socket" message on reloads and that due to the
SO_REUSEPORT in kernel 3.9 and later, additional processes are allowed to
bind to these same IPs:ports and that may be masking the issue on 3.9+
kernels.

The other thing I'm wondering is if signal_unregister_handler()
in sig_soft_stop in haproxy.c has removed all of the signal handlers that
this PID would otherwise be listening for and that's why it is unresponsive
to anything other than -SIGKILL. soft_stop() is called right
before signal_unregister_handler() so is it possible that something went
sideways while executing soft_stop(), leaving this PID sort of in limbo?

Regards,
Chris

On Fri, Oct 30, 2015 at 3:28 PM, Vincent Bernat  wrote:

>  ❦ 30 octobre 2015 15:14 -0400, Chris Riley  :
>
> > SigQ: 3/63840
> > SigPnd: 
> > SigBlk: fffe7bfa7a26
> > SigIgn: 1000
> > SigCgt: 000180300205
>
> SigIgn is correct (SIGPIPE) is ignored. However, SigBlk seems
> incorrect. HAProxy only blocks signals when dequeuing them. However, no
> signal is pending either, so they should be delivered? Maybe it was bad
> luck? If you try again, does SigBlk become 0?
> --
> Don't stop with your first draft.
> - The Elements of Programming Style (Kernighan & Plauger)
>

Re: lua TXN.set_tos not work

2015-10-30 Thread 神楽坂玲奈

if i manually modify source code and simply set tos directly. where should
i add it.
now I'm adding:

# tcp_proto.c, tcp_connect_server, line 513 - 514.

511 if (global.tune.server_rcvbuf)
512 setsockopt(fd, SOL_SOCKET, SO_RCVBUF, _rcvbuf,
sizeof(global.tune.server_rcvbuf));
513 int tos=0x10;
514 setsockopt(fd, IPPROTO_IP, IP_TOS, , sizeof(tos));
515 if ((connect(fd, (struct sockaddr *)>addr.to, get_addr_len(>
addr.to)) == -1) &&

is it correct? seems it works now, but i don't know if it will cause other
problem.

my goal is make all backend side connection have a specific TOS field. for
policy routing like this:
# ip route add default via 10.1.0.1 tos 0x10.


Willy Tarreau 于2015年10月30日周五 下午4:46写道：

> On Fri, Oct 30, 2015 at 08:16:07AM +, ??? wrote:
> > ohh.. i want to modify backend side... how to to it?
>
> It was not implemented. I noticed that the choice of action names was
> rather poor because it's confusing, no side is indicated. I think in
> 1.7 we'll have to rename some actions to make them more obvious, these
> ones included.
>
> It will be a little more difficult to implement on the backend side
> because the decision is taken before the connection is established
> so we have to store that decision somewhere. On the frontend side it
> was easy, we just find the connection's fd and perform the action
> immediately.
>
> Willy
>
>

[SPAM] Le placement 100 pourcent gagnant qui sécurise votre retraite

2015-10-30 Thread Les Senioriales

http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e2=haproxy@formilux.org=haproxy@formilux.org
 Signaler comme indésirable   


Pour visualiser ce message au format html, cliquez ici :
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e3=%40Ecne%2BMkXOK21ItvcrcZ%2ByNg59sSFWbW3vXcHm2uzRL8%3D
ou copiez le lien dans votre navigateur Web


 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e4=haproxy@formilux.org
 Jusqu'À   
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e5=haproxy@formilux.org
 63 000 € d'Économie d'impÔt   
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e6=haproxy@formilux.org
 pendant 12 ans 
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e7=haproxy@formilux.org
 avec la forte demande locative en Résidences Services Seniors nouvelle 
génération  
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e8=haproxy@formilux.org
 

Complétez vos revenus pour la retraite 
Devenez propriétaire investisseur 

 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853e9=haproxy@formilux.org
 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ea=haproxy@formilux.org
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853eb=haproxy@formilux.org
 Jusqu'à   
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ec=haproxy@formilux.org
 63 000 €   
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ed=haproxy@formilux.org
 d'économie d'impôt 
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ee=haproxy@formilux.org
 Gestion locative par Les Senioriales 

 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ef=haproxy@formilux.org
 Location possible aux ascendants / descendants 
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f0=haproxy@formilux.org
 Acteur de référence, filiale du Groupe 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f1=haproxy@formilux.org
 Pierre & Vacances - Center Parcs 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f2=haproxy@formilux.org
 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f3=haproxy@formilux.org
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f4=haproxy@formilux.org
 jusqu'À 5500€  de revenus AnticipÉs (2) 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f5=haproxy@formilux.org
 (avant même la livraison de votre bien)  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f6=haproxy@formilux.org
 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f7=haproxy@formilux.org
 
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f8=haproxy@formilux.org
 Investir en toute tranquilit  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853f9=haproxy@formilux.org
 É 
  
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853fa=haproxy@formilux.org
 Avec le spÉcialiste de la rÉsidence seniors
 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853fb=haproxy@formilux.org
 

 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853fc=haproxy@formilux.org
 Groupe 
Pierre & Vacances 
Center Parcs 

 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853fd=haproxy@formilux.org
 + de 
60 Résidences 
en France
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853fe=haproxy@formilux.org
 + de 
10 ans d'expérience 
en Résidence Séniors 
http://lb.notre-reponse.fr/r/?id=t2e9112d4,2085317,20853ff=haproxy@formilux.org
 Locataires stables 
& 
charges optimisées  


(1) Selon dispositif gouvernemental. Le non-respect des engagements de location 
entraîne la perte du bénéfice des incitations fiscales. 

(2) Sur une sélection de résidences. Rémunération par le Promoteur des appels 
de fonds versés par l'Investisseur dans le cadre de son acquisition, jusqu'à la 
livraison du bien. Rémunération due à compter de l'appel de fonds " à la 
signature de l'acte " et de son encaissement par le Promoteur. Sont à exclure 
toutes sommes non liées aux appels de fonds. Rémunération calculée sur la base 
d'un taux de l'ordre de 4% (HT ou TTC) par appel de fonds et payée par le 
Promoteur à l'Investisseur, dans la limite de 5500 euros TTC par logement et 
rémunérés à partir de 12 mois avant la livraison. Paiement de la rémunération, 
sous réserve de réception au préalable d'un coupon qui sera remis à 
l'Investisseur et de l'encaissement de l'appel de fonds dans les 15 jours de la 
réception de la notification de ce dernier. Règlement dans un délai de 30 jours 
suivant réception du coupon. Justificatif du dépôt de l'offre de prêt à fournir 
dans les 30 jours de la signature du contrat de réservation. Off
 re 
valable sur sélection de Résidences Senioriales pour toute réservation d'un 
logement neuf destiné à être loué à des Seniors

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

2015-10-30 Thread Ben Tisdall

On Thu, Oct 29, 2015 at 1:43 PM, Ben Tisdall  wrote:

> Sorry, I'm misinterpreting the test results, please ignore that. One
> ELB address has remained the same today so it's likely HAProxy has
> been using that and has not needed to update.

Ok, finally observed some more ELB address changes (2, the other
may've escaped me somehow):

Resolvers section aws
 nameserver aws_0:
  sent: 18528
  valid: 18527
  update: 3
  cname: 0
  cname_error: 0
  any_err: 0
  nx: 0
  timeout: 0
  refused: 0
  other: 0
  invalid: 0
  too_big: 0
  truncated: 0
  outdated: 1

Proxy is proxying.

-- 
Ben

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

2015-10-30 Thread Baptiste

On Fri, Oct 30, 2015 at 12:53 PM, Ben Tisdall  wrote:
> On Thu, Oct 29, 2015 at 1:43 PM, Ben Tisdall  wrote:
>
>> Sorry, I'm misinterpreting the test results, please ignore that. One
>> ELB address has remained the same today so it's likely HAProxy has
>> been using that and has not needed to update.
>
> Ok, finally observed some more ELB address changes (2, the other
> may've escaped me somehow):
>
> Resolvers section aws
>  nameserver aws_0:
>   sent: 18528
>   valid: 18527
>   update: 3
>   cname: 0
>   cname_error: 0
>   any_err: 0
>   nx: 0
>   timeout: 0
>   refused: 0
>   other: 0
>   invalid: 0
>   too_big: 0
>   truncated: 0
>   outdated: 1
>
> Proxy is proxying.
>
> --
> Ben


Hi Ben,

Thanks a lot for confirming!
I managed to run it in my lab as well a couple of hours ago to confirm
the problem is fixed.

I sent patches to Willy, and they have been integrated a few minutes ago.
You can git pull ; make clean ; make [...]

Baptiste

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

2015-10-30 Thread Baptiste

On Fri, Oct 30, 2015 at 2:10 PM, Lukas Tribus  wrote:
>> I sent patches to Willy, and they have been integrated a few minutes ago.
>> You can git pull ; make clean ; make [...]
>
> Unless you use haproxy-1.6, in that case you have to wait for the backport
> and the git push, which has not happened yet.
>
> Lukas


True :)
I'm cutting edge: "HAProxy version 1.7-dev0-e4c4b7-18".

Baptiste

RE: DNS resolution problem on 1.6.1-1ppa1~trusty

2015-10-30 Thread Lukas Tribus

> I sent patches to Willy, and they have been integrated a few minutes ago.
> You can git pull ; make clean ; make [...]

Unless you use haproxy-1.6, in that case you have to wait for the backport
and the git push, which has not happened yet.

Lukas

[SPAM] Construisez vous un nouveau patrimoine en Corse

2015-10-30 Thread Investissez en Corse

http://lb.enquete-en-or.com/r/?id=t2eda1e22,20c2127,20ba62c=haproxy@formilux.org=haproxy@formilux.org
 Signaler comme indésirable  


Pour visualiser ce message au format html, cliquez ici :
http://lb.enquete-en-or.com/r/?id=t2eda1e22,20c2127,20ba62d=%40UybZQnyoWGL%2BGDG6uwQTtmCPcdCcWDiVDS%2Bg2KF3Mcw%3D
ou copiez le lien dans votre navigateur Web



 
http://lb.enquete-en-or.com/r/?id=t2eda1e22,20c2127,20ba62e=haproxy@formilux.org

AUJOURD’HUI, LE PLAISIR D’UNE RENTABILITÉ ASSURÉE   


- DES AVANTAGES FISCAUX :  Une réduction d’impôt jusqu’ 21% sur le prix 
d’acquisition de votre logement en le louant pendant 6, 9 ou 12 ans avec la Loi 
Pinel : Jusqu’à 63 000€ d’économie d’impôts ! 

- UN INVESTISSEMENT BOOSTÉ :  La Corse faisant partie de la zone A, le 
montant des loyers est plus élevé que dans d’autres régions 

- UN POTENTIEL LOCATIF FORT TOUTE L’ANNÉE :  Les logements neufs sont 
rares et donc très prisés par les locataires de l’île 

- UN PATRIMOINE VALORISÉ :  Grâce à la croissance économique et 
démographique de l’île, à son développement et à son cadre de vie exceptionnel 

- UNE OPERATION SECURISÉE :  Vous bénéficiez de l’accompagnement d’un 
acteur référent de la gestion locative qui vous apportera toutes les garanties 
de loyers 



DEMAIN, LE PLAISIR DE PROFITER D’UNE RESIDENCE SECONDAIRE ET/OU DU POTENTIEL 
TOURISTIQUE DE LA CORSE


Vous avez toujours rêvé d’avoir un pied à terre sur cette île atypique 
et surprenante, aux multiples paysages entre mer et montagne? 
Bonne nouvelle, vous pourrez, au bout de 6, 9, ou 12 ans, transformer votre 
investissement en résidence secondaire et/ou rentabiliser votre investissement 
grâce à la location saisonnière. 
L’idéal pour vous reposer, accueillir famille et amis le temps d’un week-end ou 
pendant les vacances.   


 
http://lb.enquete-en-or.com/r/?id=t2eda1e22,20c2127,20ba62f=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2eda1e22,20c2127,20ba630=haproxy@formilux.org


Le non-respect des engagements de location entraîne la perte du bénéfice des 
incitations fiscales.  



Confidentialité des données : conformément à la Loi Informatique et 
Libertés
du 6 Janvier 1978, vous disposez d'un droit d'accès et de rectification des
données vous concernant. Vous recevez cette invitation car vous avez été en
contact avec le Service Commercial de CapDecision ou de ses partenaires. Pour ne
plus recevoir de messages de CapDecision
http://lb.capmail.fr/webApp/unsub?id=%405SxJ%2BLYrzix7UIXGcQfC0w%3D%3D; 
_label="Lien de désinscription" _type="optout">cliquez ici.

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

2015-10-30 Thread Ben Tisdall

On Fri, Oct 30, 2015 at 2:48 PM, Baptiste  wrote:
> On Fri, Oct 30, 2015 at 2:10 PM, Lukas Tribus  wrote:
>>> I sent patches to Willy, and they have been integrated a few minutes ago.
>>> You can git pull ; make clean ; make [...]
>>
>> Unless you use haproxy-1.6, in that case you have to wait for the backport
>> and the git push, which has not happened yet.
>>
> True :)
> I'm cutting edge: "HAProxy version 1.7-dev0-e4c4b7-18".
>

We use Vincent Bernat's PPA so we'll need to wait on that too.
Comparing the upstream and debian changelogs he seems pretty close
behind you folks though :)

-- 
Ben

Re: questions for haproxy 1.5

On 31/10/2015 2:03 AM, "Igor Cicimov" 
wrote:
>
>
> On 30/10/2015 11:18 PM, "Labedan, Alain"  wrote:
> >
> > Hi,
> >
> >
> >
> > I have HAPROXY in front of servers backend which are load balanced.
> >
> >
> >
> > -  For terminated SSL haproxy, I want HAproxy give the good
certificate to the client associated with the good domain .
> >
> > I’ve not found how to configure HA for that:  I ‘ve 4 domains
associated with one public IP in front . So how declare and use the 4
 certificates SSL for the 4 domains ?
> >
> >
> >
> > -  How use affinity session ? is it SERVERID insert ?
> >
> >
> >
> >
> >
> > Thanks for your answer .
> >
> > Bests regards .
> >
> >
> >
> > Alain Labedan
> >
> >
> >
> > AVIS DE CONFIDENTIALITÉ : Ce message peut contenir des renseignements
confidentiels appartenant exclusivement au Groupe CGI inc. ou à ses
filiales. Si vous n'êtes pas le destinataire indiqué ou prévu dans ce
message (ou responsable de livrer ce message à la personne indiquée ou
prévue) ou si vous pensez que ce message vous a été adressé par erreur,
vous ne pouvez pas utiliser ou reproduire ce message, ni le livrer à
quelqu'un d'autre. Dans ce cas, vous devez le détruire et vous êtes prié
d'avertir l'expéditeur en répondant au courriel.
> >
> >
> This might give you an idea http://blog.haproxy.com/category/ssl/
>
> Just use sni in the frontend (google this many examples out there) and
based on acl send the traffic to one of 4 dummy backends as in the example,
something like this
>
> acl domain1 req_ssl_sni -i www.domain1.com
> use_backend bk_domain1_sock  if domain1
>
> Then each backend and listener will bind to a socket as in the example
and each listen section will have its own certificate and point to
appropriate backend.
>
> Just a theory not sure if it will work haven't tested. Of course you need
modern browsers with sni support in order for this to work.

Sorry just noticed the link didn't  copy properly, correct one given below:
http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/

Re: questions for haproxy 1.5

On 30/10/2015 11:18 PM, "Labedan, Alain"  wrote:
>
> Hi,
>
>
>
> I have HAPROXY in front of servers backend which are load balanced.
>
>
>
> -  For terminated SSL haproxy, I want HAproxy give the good
certificate to the client associated with the good domain .
>
> I’ve not found how to configure HA for that:  I ‘ve 4 domains associated
with one public IP in front . So how declare and use the 4  certificates
SSL for the 4 domains ?
>
>
>
> -  How use affinity session ? is it SERVERID insert ?
>
>
>
>
>
> Thanks for your answer .
>
> Bests regards .
>
>
>
> Alain Labedan
>
>
>
> AVIS DE CONFIDENTIALITÉ : Ce message peut contenir des renseignements
confidentiels appartenant exclusivement au Groupe CGI inc. ou à ses
filiales. Si vous n'êtes pas le destinataire indiqué ou prévu dans ce
message (ou responsable de livrer ce message à la personne indiquée ou
prévue) ou si vous pensez que ce message vous a été adressé par erreur,
vous ne pouvez pas utiliser ou reproduire ce message, ni le livrer à
quelqu'un d'autre. Dans ce cas, vous devez le détruire et vous êtes prié
d'avertir l'expéditeur en répondant au courriel.
>
>
This might give you an idea http://blog.haproxy.com/category/ssl/

Just use sni in the frontend (google this many examples out there) and
based on acl send the traffic to one of 4 dummy backends as in the example,
something like this

acl domain1 req_ssl_sni -i www.domain1.com
use_backend bk_domain1_sock  if domain1

Then each backend and listener will bind to a socket as in the example and
each listen section will have its own certificate and point to appropriate
backend.

Just a theory not sure if it will work haven't tested. Of course you need
modern browsers with sni support in order for this to work.

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Willy,

The permissions where one of the first things I checked. consul-template
runs as root in order to be able to reload/restart daemon and it's using
the same init script that the system uses on startup. Not all of the
reloads fail, the first few initial ones are successful. What's odd is that
the behavior goes away when I failover all IPs to one server and
set net.ipv4.ip_nonlocal_bind=0. After that all reloads are successful, no
matter how many times in a row reload is called. The issue remains at bay
even after failing half of the IPs back over to the secondary server and
setting net.ipv4.ip_nonlocal_bind=1 again. That is until the servers
reboot, then the behavior returns. Vincent got me thinking about the 2.6.32
kernel that is part of CentOS 6.4. I'm wondering if
net.ipv4.ip_nonlocal_bind behaves oddly in 2.6.x with respect to the status
of existing socket file descriptors. I'm going to try kernel 3.10 from
CentOS 7 to see if I can reproduce it in 3.10 in order to rule out or
confirm an issue with the kernel.

However, I'm not sure that's the issue. When a reload fails there is
nothing in the log file that indicates that haproxy saw SIGTTOU or SIGUSR1
("Pausing %s %s." and "Stopping %s %s in %d ms."). I can reproduce this
behavior if I don't provide a PID to -sf. When looking at the code
in proxy.c it looks like pause_proxy() is either not being called
by pause_proxies in haproxy.c (due to the missed SIGTTOU) or in
pause_proxy() the proxy state check is returning 1 at the top of the
pause_proxy() function. I'm going to add some additional logging statements
to see if I can isolate what's happening.

Regards,
Chris

On Fri, Oct 30, 2015 at 3:11 AM, Willy Tarreau  wrote:

> On Fri, Oct 30, 2015 at 08:04:48AM +0100, Vincent Bernat wrote:
> >  ??? 30 octobre 2015 00:34 -0400, Chris Riley  :
> >
> > > The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS
> > > 6.4.
> >
> > With this version of the kernel, the previous instance of HAProxy has to
> > release the port before the new one can bind. It seems that in your
> > case, this doesn't happen. Nothing suspicious in the logs of the
> > previous instance?
>
> It would be nice to ensure the process is reloaded with appropriate
> permissions. The new process indeed needs to send a signal to the old
> process, and bind to the ports. If any of these operations fail, it will
> not be able to start.
>
> Willy
>
>

Multiple nameservers with the same ID is allowed

2015-10-30 Thread Pavlos Parissis

Hi,

Following resolver section passes configuration check
resolvers mydns1
nameserver ns1 8.8.8.8:53
nameserver ns1 8.8.4.4:53
resolve_retries   3
timeout retry 1s
hold valid   10s

IMHO: allowing same ID for 2 different objects, which have stats attached
to them, may not be the best approach here. Since, HAProxy doesn't allow
more than one resolver sections with same name, I would say for consistency
reasons should do the same for nameserver parameters within the same
resolver section.

If IDs for nameserver are different then you can fetch stats per nameserver:
echo 'show stat resolvers mydns1 ns1'|socat /run/haproxy/admin1.sock stdio

Cheers,
Pavlos

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Vincent,

What's odd is that if I failover all virtual IPs to one server and
set net.ipv4.ip_nonlocal_bind=0 on that server the issue goes away. The
issue remains "fixed" when I fail half of the virtual IPs back to the
secondary server and set net.ipv4.ip_nonlocal_bind=1. However, after a
reboot of both servers the initial behavior comes back. This seems to be
something related to the way the 2.6.32 kernel handles
net.ipv4.ip_nonlocal_bind and how it relates to the sockets' file
descriptors.

The logs don't show anything suspicious. When a reload is successful I see
the expected output in the logs:

Oct 30 09:49:53 127.0.0.1 haproxy[26191]: Proxy haproxy-stats started.
Oct 30 09:50:22 127.0.0.1 haproxy[26192]: Pausing proxy haproxy-stats.
Oct 30 09:50:22 127.0.0.1 haproxy[26215]: Proxy haproxy-stats started.
Oct 30 09:50:22 127.0.0.1 haproxy[26192]: Stopping proxy haproxy-stats in 0
ms.
Oct 30 09:50:22 127.0.0.1 haproxy[26192]: Proxy haproxy-stats stopped (FE:
0 conns, BE: 0 conns).

When a reload is unsuccessful the code that pauses, starts a new proxy, and
stops the original proxy isn't called so there is no output in the logs.
Instead the Alert (cannot bind socket) is sent to stderr and is logged by
consul-template.

I'm going to compile the 3.10 kernel from CentOS 7 for CentOS 6 and see if
the behavior persists and report back.

Thanks,
Chris

On Fri, Oct 30, 2015 at 3:04 AM, Vincent Bernat  wrote:

>  ❦ 30 octobre 2015 00:34 -0400, Chris Riley  :
>
> > The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS
> > 6.4.
>
> With this version of the kernel, the previous instance of HAProxy has to
> release the port before the new one can bind. It seems that in your
> case, this doesn't happen. Nothing suspicious in the logs of the
> previous instance?
> --
> Let us endeavor so to live that when we come to die even the undertaker
> will be
> sorry.
> -- Mark Twain, "Pudd'nhead Wilson's Calendar"
>

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

 ❦ 30 octobre 2015 10:50 -0400, Chris Riley  :

> I'm going to compile the 3.10 kernel from CentOS 7 for CentOS 6 and
> see if the behavior persists and report back.

With a 3.10, you are unlikely to get the same behaviour as two processes
are allowed to listen to the same IP/port. So, if it's a possibility for
you, it is likely to solve the problem.
-- 
Harp not on that string.
-- William Shakespeare, "Henry VI"

[SPAM] -50 euros pour vous immediatement

2015-10-30 Thread Blancheporte par capdecision

http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c6698=haproxy@formilux.org=haproxy@formilux.org
 Signaler comme indésirable  


Pour visualiser ce message au format html, cliquez ici :
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c6699=%40WAXxYBZvQDOxfDAchED%2BiSjA5JVs4U%2BlqMPwkcHjsGc%3D
ou copiez le lien dans votre navigateur Web



 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669a=haproxy@formilux.org
 Dites OUI aux prix accessibles et à la qualité de notre 
collection Mode & Maison Automne-Hiver 2015 !   


 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669b=haproxy@formilux.org


 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669c=haproxy@formilux.org
 Femme  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669d=haproxy@formilux.org
 Lingerie  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669e=haproxy@formilux.org
 Homme  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c669f=haproxy@formilux.org
 Grande Taille  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a0=haproxy@formilux.org
 Linge de Maison  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a1=haproxy@formilux.org
 Maison  •   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a2=haproxy@formilux.org
 Bonnes affaires

 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a3=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a4=haproxy@formilux.org
 GÉnial ! 
-50 € 
dès 99€ d’achat* 


 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a5=haproxy@formilux.org
 > Je craque !  


 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a6=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a7=haproxy@formilux.org



 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a8=haproxy@formilux.org
 Joyeux coloris de saison, styles inspirés des dernières tendances mode, 
détails de confection séduisants et coupes étudiées, tailles jusqu’au 58… 
Nous avons beaucoup à vous offrir. 
Faisons connaissance en toute simplicité !  


 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66a9=haproxy@formilux.org
 > JE DÉCOUVRE !





 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66aa=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66ab=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66ac=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66ad=haproxy@formilux.org

 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66ae=haproxy@formilux.org
 > Noël  
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66af=haproxy@formilux.org
 > Lingerie  
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b0=haproxy@formilux.org
 > Grande taille 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b1=haproxy@formilux.org
 > Linge de maison  




 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b2=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b3=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b4=haproxy@formilux.org
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b5=haproxy@formilux.org

 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b6=haproxy@formilux.org
 Paiement sécurisé   
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b7=haproxy@formilux.org
 Satisfait ou remboursé  
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b8=haproxy@formilux.org
 Livraison à domicile
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66b9=haproxy@formilux.org
 Suivi de commande  




 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66ba=haproxy@formilux.org
 Le shopping facile en 3 clics !

 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66bb=haproxy@formilux.org
 1°  
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66bc=haproxy@formilux.org
 REMPLISSEZ 
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66bd=haproxy@formilux.org
 votre panier, vos réductions 
s'additionnent toutes seules

 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66be=haproxy@formilux.org
 2°  
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66bf=haproxy@formilux.org
 DÉCIDEZ
 
http://lb.enquete-en-or.com/r/?id=t2ee1594c,20c6520,20c66c0=haproxy@formilux.org
 de votre livraison et payez 
comme vous voulez,

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Chris,

On Fri, Oct 30, 2015 at 11:18:30AM -0400, Chris Riley wrote:
> Hi Willy,
> 
> The permissions where one of the first things I checked. consul-template
> runs as root in order to be able to reload/restart daemon and it's using
> the same init script that the system uses on startup. Not all of the
> reloads fail, the first few initial ones are successful. What's odd is that
> the behavior goes away when I failover all IPs to one server and
> set net.ipv4.ip_nonlocal_bind=0.

That's really strange.

> After that all reloads are successful, no
> matter how many times in a row reload is called. The issue remains at bay
> even after failing half of the IPs back over to the secondary server and
> setting net.ipv4.ip_nonlocal_bind=1 again. That is until the servers
> reboot, then the behavior returns. Vincent got me thinking about the 2.6.32
> kernel that is part of CentOS 6.4. I'm wondering if
> net.ipv4.ip_nonlocal_bind behaves oddly in 2.6.x with respect to the status
> of existing socket file descriptors.

No, nonlocal_bind hasn't changed for a while, what was brought later (3.9)
was SO_REUSEPORT which haproxy always uses, so that makes it easier to
rebind regardless of the presence of an old process.

> I'm going to try kernel 3.10 from
> CentOS 7 to see if I can reproduce it in 3.10 in order to rule out or
> confirm an issue with the kernel.

It should work better but will very likely hide the root cause. I suspect
you'll find two processes running after a reload because the old one doesn't
stop then.

> However, I'm not sure that's the issue. When a reload fails there is
> nothing in the log file that indicates that haproxy saw SIGTTOU or SIGUSR1
> ("Pausing %s %s." and "Stopping %s %s in %d ms."). I can reproduce this
> behavior if I don't provide a PID to -sf. When looking at the code
> in proxy.c it looks like pause_proxy() is either not being called
> by pause_proxies in haproxy.c (due to the missed SIGTTOU) or in
> pause_proxy() the proxy state check is returning 1 at the top of the
> pause_proxy() function. I'm going to add some additional logging statements
> to see if I can isolate what's happening.

That would confirm the possibility that the signal is not sent at all,
or at least not to the right process. Could you check the exact command
that is started, to ensure the pids are correct (or present at all) ?
Can you also try by hand to first send SIGUSR1 to the old process,
then perform the reload, then send SIGTTOU by hand to the old one ?
If it works, it would confirm an issue with the ability to send a
signal to the old process from the new one.

Regards,
Willy

Re: Need some help configuring backend health checks

2015-10-30 Thread Daren Sefcik

On Thu, Oct 29, 2015 at 11:15 PM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

>
> On 30/10/2015 4:48 PM, "Daren Sefcik"  wrote:
> >
> > So I think those links were the right idea and I have been trying
> different configurations but am not quite there and am hoping somebody can
> offer a bit more guidance.
> >
> > So when I telnet to the icap server I type in the OPTIONS line followed
> by (2) return key presses and then it returns the ICAP text, below is my
> telent session output
> >
> > ===
> >
> > $ telnet 10.1.4.153 1344
> > Trying 10.1.4.153...
> > Connected to 10.1.4.153.
> > Escape character is '^]'.
> > OPTIONS icap://127.0.0.1:1344/respmod ICAP/1.0
> >
> > ICAP/1.0 200 OK
> > ISTAG: "5BDEEEA9-12E4-2"
> > Service: Diladele Web Safety 4.2.0.CBF4
> > Service-ID: qlproxy
> > Methods: RESPMOD
> > Options-TTL: 3600
> > Max-Connections: 15000
> > Allow: 204
> > Preview: 4096
> > Transfer-Preview: *
> > Encapsulated: null-body=0
> > Connection: close
> >
> > 
> >
> >
> > Here is what I have tried in the backend configurations
> >
> > option tcp-check
> > tcp-check send OPTIONS\ icap\:\/\/127\.0\.0\.1\:1344\/respmod\
> ICAP\/1\.0\r\n\
> > tcp-check send \r\n
> > tcp-check expect string ICAP\/1\.0\ 200\ OK
> >
> >
> > but it is still not working, I suspect I need to use some type of regex
> or such. Hoping somebody can help me along with this.
> >
> > TIA..
> >
> >
> > On Mon, Oct 19, 2015 at 7:42 AM, Daren Sefcik 
> wrote:
> >>
> >> Thanks Jarno, I am still not sure how I can apply this to each server
> using a different port but will poke around at it and see if I can figure
> it out.
> >>
> >> On Mon, Oct 19, 2015 at 1:04 AM, Jarno Huuskonen <
> jarno.huusko...@uef.fi> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sun, Oct 18, Daren Sefcik wrote:
> >>> > I have an ICAP server backend with servers that each listen on
> different
> >>> > ports, can anyone offer some advice on how to configure health
> checks for
> >>> > it? I am currently using basic but that really doesn't help if the
> service
> >>> > is not responding.
> >>> >
> >>> > Here is my haproxy config for the backend:
> >>> >
> >>> > backend HTPL_CONT_FILTER_tcp_ipvANY
> >>> > mode tcp
> >>> > balance roundrobin
> >>> > timeout connect 5
> >>> > timeout server 5
> >>> > retries 3
> >>> > server HTPL-WEB-01_10.1.4.153 10.1.4.153:1344 check inter 5000
> weight 200
> >>> > maxconn 200 fastinter 1000 fall 5
> >>> > server HTPL-WEB-02_10.1.4.154 10.1.4.154:1344 check inter 5000
> weight 200
> >>> > maxconn 200 fastinter 1000 fall 5
> >>> > server HTPL-WEB-02_10.1.4.155_01 10.1.4.155:8102 check inter 5000
> weight
> >>> > 200 maxconn 200 fastinter 1000 fall 5
> >>> > server HTPL-WEB-02_10.1.4.155_02 10.1.4.155:8202 check inter 5000
> weight
> >>> > 200 maxconn 200 fastinter 1000 fall 5
> >>>
> >>> Do the icap servers (squid+diladele?) respond to something like this:
> >>> https://support.symantec.com/en_US/article.TECH220980.html
> >>> or
> https://exchange.icinga.org/oldmonex/1733-check_icap.pl/check_icap.pl
> >>>
> >>> Maybe you can use tcp-check to send icap request and look for
> >>> "ICAP/1.0 200" response:
> >>>
> https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#tcp-check%20connect
> >>>
> http://blog.haproxy.com/2014/01/02/haproxy-advanced-redis-health-check/
> >>>
> >>> -Jarno
> >>>
> >>> --
> >>> Jarno Huuskonen
> >>
> >>
> >
> Since your telnet session is on port 1344, maybe
>
> tcp-check connect port 1344
>
> before the send command.
>
Thank you but each backend server has a different port configured, that is
just one example.


server HTPL-WEB-01_10.1.4.153 10.1.4.153:1344 check inter 5000  weight 200
maxconn 200 fastinter 1000 rise 1 fall 5
server HTPL-WEB-02_10.1.4.154 10.1.4.154:1344 check inter 5000  weight 200
maxconn 200 fastinter 1000 rise 1 fall 5
server HTPL-WEB-02-DOCK-02_10.1.4.155_01 10.1.4.155:8102 check inter 5000
 weight 200 maxconn 200 fastinter 1000 rise 1 fall 5
server HTPL-WEB-02-DOCK-02_10.1.4.155_02 10.1.4.155:8202 check inter 5000
 weight 200 maxconn 200 fastinter 1000 rise 1 fall 5

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Willy,

Thanks for your quick reply.

> It should work better but will very likely hide the root cause. I suspect
> you'll find two processes running after a reload because the old one
> doesn't stop then.

Yep, that's exactly what I'm seeing with 3.10. I've got a bunch of haproxy
processes stacked up, all with an -sf flag and each being passed the PID of
the previous process. The only one not in the process list is the initial
haproxy instance created when 'service haproxy start' was first run.

lb-01 ~ [qa] # ps ax | grep hap
 2834 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2822
 2871 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2859
 2883 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2871
 2910 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2896
 2922 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2910
 2947 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2934
 2959 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2947
 2962 pts/1S+ 0:00 grep --colour=auto hap


> That would confirm the possibility that the signal is not sent at all,
> or at least not to the right process. Could you check the exact command
> that is started, to ensure the pids are correct (or present at all) ?
> Can you also try by hand to first send SIGUSR1 to the old process,
> then perform the reload, then send SIGTTOU by hand to the old one ?
> If it works, it would confirm an issue with the ability to send a
> signal to the old process from the new one.

'service haproxy start' invokes this:

daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid

which produces:

usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid

ps ax shows:

2822 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid

cat /var/run/haproxy.pid shows:
2822

'service haproxy reload' invokes this:

$exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat
/var/run/$prog.pid)

which produces:

2834 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
-p /var/run/haproxy.pid -sf 2822

cat /var/run/haproxy.pid then shows:
2834

I'll try manually sending SIGUSR1 and SIGTTOU as you suggested and see if I
can determine what's happening.

Any chance that this issue is related to or that same as this one?

https://github.com/haproxy/haproxy/issues/48

Regards,
Chris

On Fri, Oct 30, 2015 at 11:50 AM, Willy Tarreau  wrote:

> Hi Chris,
>
> On Fri, Oct 30, 2015 at 11:18:30AM -0400, Chris Riley wrote:
> > Hi Willy,
> >
> > The permissions where one of the first things I checked. consul-template
> > runs as root in order to be able to reload/restart daemon and it's using
> > the same init script that the system uses on startup. Not all of the
> > reloads fail, the first few initial ones are successful. What's odd is
> that
> > the behavior goes away when I failover all IPs to one server and
> > set net.ipv4.ip_nonlocal_bind=0.
>
> That's really strange.
>
> > After that all reloads are successful, no
> > matter how many times in a row reload is called. The issue remains at bay
> > even after failing half of the IPs back over to the secondary server and
> > setting net.ipv4.ip_nonlocal_bind=1 again. That is until the servers
> > reboot, then the behavior returns. Vincent got me thinking about the
> 2.6.32
> > kernel that is part of CentOS 6.4. I'm wondering if
> > net.ipv4.ip_nonlocal_bind behaves oddly in 2.6.x with respect to the
> status
> > of existing socket file descriptors.
>
> No, nonlocal_bind hasn't changed for a while, what was brought later (3.9)
> was SO_REUSEPORT which haproxy always uses, so that makes it easier to
> rebind regardless of the presence of an old process.
>
> > I'm going to try kernel 3.10 from
> > CentOS 7 to see if I can reproduce it in 3.10 in order to rule out or
> > confirm an issue with the kernel.
>
> It should work better but will very likely hide the root cause. I suspect
> you'll find two processes running after a reload because the old one
> doesn't
> stop then.
>
> > However, I'm not sure that's the issue. When a reload fails there is
> > nothing in the log file that indicates that haproxy saw SIGTTOU or
> SIGUSR1
> > ("Pausing %s %s." and "Stopping %s %s in %d ms."). I can reproduce this
> > behavior if I don't provide a PID to -sf. When looking at the code
> > in proxy.c it looks like pause_proxy() is either not being called
> > by pause_proxies in haproxy.c (due to the missed SIGTTOU) or in
> > pause_proxy() the proxy state check is returning 1 at the top of the
> > pause_proxy() function. I'm going to add some additional logging
> statements
> > to see if I can

L’actualité hebdomadaire par RFI - Viande et cancer: le vrai, le faux, la peur et la...

2015-10-30 Thread RFI L'HEBDO

L’actualité hebdomadaire par RFI - 30/10/2015

Visualisez cet email dans votre navigateur

http://rfi.nlfrancemm.com/HM?b=5M8CwQILhCGytX6Ga1letFxUOoGtUCbS3twePS0KWq-csjoaLIyf1lrKR0dgJ2Uo=0gw6JwOJIwzmY1VeDY5ZZQ

Viande et cancer: le vrai, le faux, la peur et la raison
En déclarant cancérogène la charcuterie et probablement aussi la viande rouge,
l’agence du cancer de l’Organisation mondiale de la santé (OMS) a jeté un sacré
pavé dans nos assiettes. Est-on condamné à devenir végétarien pour sauver notre
peau ? Jusqu’à quel point faut-il avoir peur de la viande ?
http://rfi.nlfrancemm.com/HP?b=2rR-PaJ3r8KJeJrk0PnzBajdYqX_RzxwVtF8cYibS6J8maq1UM7nDjJ3MTGINyb6=DTBkM4VpN_gnpmF_HkrSMw
La Pologne, nouvel eldorado des vendeurs d'armes
La Pologne veut donner du poids à ses armées, et pour cela, elle investit
massivement dans ses matériels militaires. Il n'en fallait pas plus pour
attirer de nombreux industriels de ce secteur, intéressés par une grosse
dizaine de contrats particulièrement juteux : des sous-marins, des hélicoptères
ou encore des missiles.
http://rfi.nlfrancemm.com/HP?b=u769AJsiZAlQZ2WRg9_OcRxB6XdtY2y2MjUTTGZSIK-f3ejgN-oXLwlS81dt3oF-=Ok_boGpIvXWMs1ZvvpzByw
Les dix innovateurs africains
Tests de dépistage, techniques de reforestation, logiciels, plantes résistantes
à la sécheresse, paiement par carte de crédit sans fil… Les Africains innovent,
et pas seulement au Nigeria, au Kenya et en Afrique du Sud. Du Burkina au
Rwanda, en passant par le Cameroun et la diaspora, des jeunes et moins jeunes
se distinguent par leurs inventions.
http://rfi.nlfrancemm.com/HP?b=y7vl4mwCUY-_RLAviKNzIXnn2ly5C1fqPyrMjlE_5MU9xxytETnVoodnwvD4ieJP=zQ1CQiO1VN2K0-Am1_CuUQ
Un demi-siècle après sa disparition, le mystère Ben Barka reste entier
Le 29 octobre 1965 à Paris, l’opposant marocain et icône du mouvement
tiers-mondiste Mehdi Ben Barka disparaît. Cinquante ans après son enlèvement,
le mystère est intact et de nombreuses raisons d’Etat semblent faire toujours
entrave à la justice. Pourtant, la quête de vérité continue.
http://rfi.nlfrancemm.com/HP?b=kxBvHYxxyO_09kYsW_T--GD2bR0KOBGkZDLlV8dtbp_ZKSoedqUWDpuOn3Jt101w=n__RIk4OYmLFPdULLq4DMw
Luaty Beirão, le rappeur qui inquiète Luanda
« Je suis un kamikaze angolais et voici ma mission ». Lorsqu’il compose ces
rimes, Luaty Beirão, alias Ikonoklasta, ne pensait peut-être pas les appliquer
à la lettre. Son engagement politique l’y a pourtant poussé. Appels sur
l’actualité revient sur le cas de ce rappeur et opposant politique qui a décidé
de mettre un terme à sa grève de la faim après un bras de fer qui aura duré
trente-six jours avec le régime du président Dos Santos.
http://rfi.nlfrancemm.com/HP?b=nRPHATJN1DstzbKLaaYpb-PbdILszBjlZb4zvxy3-uOpQjj3AxnFYNnwc6rMIz_-=XmZr2V0OlwM_c-lTwCb4GQ
Le boom événementiel de l'art contemporain africain
L’Occident vibre de nouveau pour la création africaine. Cette fois, il ne
s’agit pas d’art premier mais d’art contemporain : foisonnant, désarçonnant,
plus que jamais dans son temps. Et depuis deux ans, les événements autour de
cet art se multiplient à Paris, Londres ou New York. L’art africain serait-il
du nouveau chic ?
http://rfi.nlfrancemm.com/HP?b=tzpnU8XrRpww9RSVhUXptCiv5J9HvNCITgussCjTT23S8v8YybA7KIL45X4lcMVq=atpe4KpMDa_0vINc_WsbtA

Inde / Afrique : de Bollywood aux antirétroviraux
Ce jeudi 29 octobre 2015, c’est le dernier jour du troisième Sommet
Inde-Afrique, qui s’est ouvert en début de semaine à New Delhi. Une quarantaine
de chefs d’Etats et de gouvernements africains ont été invités. Car on parle
beaucoup de la Chine en Afrique, mais l’Inde est elle aussi bien présente sur
le continent, et depuis longtemps – même si ce n’est pas dans les mêmes
proportions gargantuesques que la Chine. Les liens sont bien sûr économiques,
mais aussi affectifs comme vous allez le découvrir avec nos correspondants au
Sénégal, en RDC, en Afrique du Sud et, bien sûr, en Inde. Un Grand reportage
coordonné et présenté par Christophe Paget.
http://rfi.nlfrancemm.com/HP?b=QMKwP_BrZ_VEt_qPVYdF3t9OBeUrvJKGajy1JBKzD6QnFPVzJeumaxyZ6VHosjvt=ovGYasWlnaYLIc7_DPyzcQ
Allemagne: beaucoup de réfugiés se convertissent au christianisme
Comme un peu partout en Europe de l'ouest, la pratique religieuse disparait peu
à peu dans les églises allemandes. Et pourtant, une paroisse berlinoise ne
désemplit pas. L’Eglise de la Sainte Trinité, une communauté évangélique
luthérienne indépendante, accueille en son sein de nouveaux convertis. Sur le
point de fermer ses portes en 2008, elle compte aujourd’hui plus de 850
membres, dont 600 originaires d’Iran et d’Afghanistan. La plupart d’entre eux
sont des réfugiés, qui se sont convertis au christianisme à leur arrivée en
Allemagne.
http://rfi.nlfrancemm.com/HP?b=VfFVeoqlGJTI9GRlW1VTeTqsJ2nwACBZkUrknKXQEjy6RjHEL_2YvY7-e1eQ4pN3=IvsR_VnsHS9-A3I60RKotw
Mission Médecins du Monde en banlieue
À Saint-Denis, dans le département de la Seine-Saint-Denis dans le 93, la
mission banlieue de Médecins du Monde

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Vincent,

Thanks for your quick reply. I tried with 3.10 and the reloads don't "fail"
as they do with 2.6 but the stacking up of haproxy processes that Willy
mentioned might occur does happen. It looks like for some reason the new
process is having an issue sending signals to the old process. I'm
following Willy's suggestions to try to determine what may be happening.

Regards,
Chris

On Fri, Oct 30, 2015 at 10:54 AM, Vincent Bernat  wrote:

>  ❦ 30 octobre 2015 10:50 -0400, Chris Riley  :
>
> > I'm going to compile the 3.10 kernel from CentOS 7 for CentOS 6 and
> > see if the behavior persists and report back.
>
> With a 3.10, you are unlikely to get the same behaviour as two processes
> are allowed to listen to the same IP/port. So, if it's a possibility for
> you, it is likely to solve the problem.
> --
> Harp not on that string.
> -- William Shakespeare, "Henry VI"
>

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

 ❦ 30 octobre 2015 14:50 -0400, Chris Riley  :

> Good idea. I just tried and it appears to be in an epoll_wait loop.
> This is after sending the PID SIGTTOU and SIGUSR1. SIGTERM also has no
> effect, the process stays in this epoll_wait loop.
>
> strace -p11537
> Process 11537 attached - interrupt to quit
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, {}, 200, 1000) = 0
> epoll_wait(0, ^C 
> Process 11537 detached

It stays in the epoll loop even while you are sending the signals? Could
you also check what you get with "grep '^Sig' /proc/PID/status"?
-- 
When one burns one's bridges, what a very nice fire it makes.
-- Dylan Thomas

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Vincent,

> It stays in the epoll loop even while you are sending the signals? Could
> you also check what you get with "grep '^Sig' /proc/PID/status"?

Yes, it stays in the epoll loop when sending any signal other than
-SIGKILL. I'm poking around with gdb to see if I can see anything. This is
the backtrace:

(gdb) bt
#0  0x003bf84e8f23 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1  0x0049e886 in _do_poll ()
#2  0x00406a3b in run_poll_loop ()
#3  0x00409e61 in main ()

And here is the output of grep '^Sig' /proc/11537/status

SigQ:   3/63840
SigPnd: 
SigBlk: fffe7bfa7a26
SigIgn: 1000
SigCgt: 000180300205

Regards,
Chris

On Fri, Oct 30, 2015 at 3:09 PM, Vincent Bernat  wrote:

>  ❦ 30 octobre 2015 14:50 -0400, Chris Riley  :
>
> > Good idea. I just tried and it appears to be in an epoll_wait loop.
> > This is after sending the PID SIGTTOU and SIGUSR1. SIGTERM also has no
> > effect, the process stays in this epoll_wait loop.
> >
> > strace -p11537
> > Process 11537 attached - interrupt to quit
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, {}, 200, 1000) = 0
> > epoll_wait(0, ^C 
> > Process 11537 detached
>
> It stays in the epoll loop even while you are sending the signals? Could
> you also check what you get with "grep '^Sig' /proc/PID/status"?
> --
> When one burns one's bridges, what a very nice fire it makes.
> -- Dylan Thomas
>

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

 ❦ 30 octobre 2015 15:14 -0400, Chris Riley  :

> SigQ: 3/63840
> SigPnd: 
> SigBlk: fffe7bfa7a26
> SigIgn: 1000
> SigCgt: 000180300205

SigIgn is correct (SIGPIPE) is ignored. However, SigBlk seems
incorrect. HAProxy only blocks signals when dequeuing them. However, no
signal is pending either, so they should be delivered? Maybe it was bad
luck? If you try again, does SigBlk become 0?
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

On Fri, Oct 30, 2015 at 12:23:57PM -0400, Chris Riley wrote:
> Hi Willy,
> 
> Thanks for your quick reply.
> 
> > It should work better but will very likely hide the root cause. I suspect
> > you'll find two processes running after a reload because the old one
> > doesn't stop then.
> 
> Yep, that's exactly what I'm seeing with 3.10. I've got a bunch of haproxy
> processes stacked up, all with an -sf flag and each being passed the PID of
> the previous process. The only one not in the process list is the initial
> haproxy instance created when 'service haproxy start' was first run.
> 
> lb-01 ~ [qa] # ps ax | grep hap
>  2834 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2822
>  2871 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2859
>  2883 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2871
>  2910 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2896
>  2922 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2910
>  2947 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2934
>  2959 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2947
>  2962 pts/1S+ 0:00 grep --colour=auto hap

These ones don't all match, in fact only the last one is fine. That's
strange.

> > That would confirm the possibility that the signal is not sent at all,
> > or at least not to the right process. Could you check the exact command
> > that is started, to ensure the pids are correct (or present at all) ?
> > Can you also try by hand to first send SIGUSR1 to the old process,
> > then perform the reload, then send SIGTTOU by hand to the old one ?
> > If it works, it would confirm an issue with the ability to send a
> > signal to the old process from the new one.
> 
> 'service haproxy start' invokes this:
> 
> daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid
> 
> which produces:
> 
> usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
> 
> ps ax shows:
> 
> 2822 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid
> 
> cat /var/run/haproxy.pid shows:
> 2822
> 
> 'service haproxy reload' invokes this:
> 
> $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat
> /var/run/$prog.pid)

OK so there is no reason for it not to work.

> which produces:
> 
> 2834 ?Ss 0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg
> -p /var/run/haproxy.pid -sf 2822
> 
> cat /var/run/haproxy.pid then shows:
> 2834
> 
> I'll try manually sending SIGUSR1 and SIGTTOU as you suggested and see if I
> can determine what's happening.

Yes that will definitely help.
> 
> Any chance that this issue is related to or that same as this one?
> 
> https://github.com/haproxy/haproxy/issues/48

Looks similar indeed. RHEL has selinux enabled by default I believe, I
don't know if that could prevent haproxy from sending a signal to another
process. Maybe you can try to stop it (if enabled at all).

Regards,
Willy

possible crashing?

2015-10-30 Thread Donovan Meyers


Hey all,

I'm currently investigating some possible crashing in 1.5.14.

I really hate to call it a crash since I've never seen haproxy crash in my
life until now, but the process is suddenly not running and I can't figure
out why.

I've checked syslogs and puppet logs (and now disabled puppet) and anything
else that could stop the process for any reason. There are no messages
related to haproxy stopping at all.

I turned haproxy logging up to debug but there's nothing in the log when it
happens. I keep a stats page reloading on my desktop, so the log has entries
for those requests, and then suddenly nothing.

The issue doesn't seem related to load; under load testing the issue doesn't
manifest (not right away anyway) and it does manifest under no load at all.

The config is extremely simple; I'm happy to post it if anyone's interested.
But it's not doing anything interesting.

I've now enabled core dumps and even have it running under valgrind memcheck
but unfortunately I haven't gotten it to happen since I did that.

The binary is one I compiled from source in order to build an RPM, using the
haproxy.spec from the CentOS 6.5 haproxy-1.4.24-2.el6.src.rpm, slightly
tweaked. For valgrind I also added CFLAGS="-g -O0".

I really hope I can figure out that it's my fault. Barring that, I hope I
can ferret out an issue with haproxy and contribute that to the community
that has been so helpful to me. (Although you won't see a patch from me; I'm
no developer! :) )

So this message may seem premature since I haven't found anything, but I'm
sending it:

1. To ask if there's a known bug that could cause this
2. To give a heads up that I may have found something
3. To ask for any recommendations on how to determine what's happening

Thanks in advance,
Donovan

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

gdb shows this when attached to the same process:

0x003bf84e8f23 in __epoll_wait_nocancel () from /lib64/libc.so.6

Regards,
Chris

On Fri, Oct 30, 2015 at 2:38 PM, Vincent Bernat  wrote:

>  ❦ 30 octobre 2015 14:36 -0400, Chris Riley  :
>
> > When the processes stack up, the old ones don't respond to anything
> > other than 'kill -9'.
>
> You could try to strace them to check where they currently are.
> --
> If more of us valued food and cheer and song above hoarded gold, it would
> be a merrier world.
> -- J.R.R. Tolkien
>

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

Hi Willy,

I tried manually sending SIGUSR1 and SIGTTOU as you suggested but I had
mixed results. Sometimes the procs would do what I expected and sometimes
they wouldn't.

> Looks similar indeed. RHEL has selinux enabled by default I believe, I
> don't know if that could prevent haproxy from sending a signal to
> another process. Maybe you can try to stop it (if enabled at all).

selinux is disabled on these hosts. I tried with an infinite while loop
like in the github post but I can't force it to happen. I tried rapid fire,
with a 1 second pause, and with a small random rewrite to haproxy.cfg
before the reload (to mimic a change written out by consul-template) and no
matter how long I let the while loop run, the previous process always
cleanly exists - with and without traffic passing through it (stats page
continually refreshing)

while :; do service haproxy reload; done

while :; do service haproxy reload; sleep 1; done

while :; do /etc/haproxy/test.sh; service haproxy reload; sleep 1; done

test.sh:

#!/bin/bash
sed "s/<>/$RANDOM/" /etc/haproxy/haproxy.cfg.tmpl >
/etc/haproxy/haproxy.cfg

I'm going to take a closer look at the source for consul-template (
https://github.com/hashicorp/consul-template) to see if it manipulates the
command provided in the template configuration or if it blindly passes it
to the shell. This is what the config looks like for consul-template:

template {
  source = "/etc/consul-template/templates/haproxy.cfg.ctmpl"
  destination = "/etc/haproxy/haproxy.cfg"
  command = "/sbin/service haproxy reload || true"
}

I will let you know if I find anything of interest.

Regards,
Chris

On Fri, Oct 30, 2015 at 1:20 PM, Willy Tarreau  wrote:

> On Fri, Oct 30, 2015 at 12:23:57PM -0400, Chris Riley wrote:
> > Hi Willy,
> >
> > Thanks for your quick reply.
> >
> > > It should work better but will very likely hide the root cause. I
> suspect
> > > you'll find two processes running after a reload because the old one
> > > doesn't stop then.
> >
> > Yep, that's exactly what I'm seeing with 3.10. I've got a bunch of
> haproxy
> > processes stacked up, all with an -sf flag and each being passed the PID
> of
> > the previous process. The only one not in the process list is the initial
> > haproxy instance created when 'service haproxy start' was first run.
> >
> > lb-01 ~ [qa] # ps ax | grep hap
> >  2834 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2822
> >  2871 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2859
> >  2883 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2871
> >  2910 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2896
> >  2922 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2910
> >  2947 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2934
> >  2959 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2947
> >  2962 pts/1S+ 0:00 grep --colour=auto hap
>
> These ones don't all match, in fact only the last one is fine. That's
> strange.
>
> > > That would confirm the possibility that the signal is not sent at all,
> > > or at least not to the right process. Could you check the exact command
> > > that is started, to ensure the pids are correct (or present at all) ?
> > > Can you also try by hand to first send SIGUSR1 to the old process,
> > > then perform the reload, then send SIGTTOU by hand to the old one ?
> > > If it works, it would confirm an issue with the ability to send a
> > > signal to the old process from the new one.
> >
> > 'service haproxy start' invokes this:
> >
> > daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid
> >
> > which produces:
> >
> > usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
> >
> > ps ax shows:
> >
> > 2822 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid
> >
> > cat /var/run/haproxy.pid shows:
> > 2822
> >
> > 'service haproxy reload' invokes this:
> >
> > $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat
> > /var/run/$prog.pid)
>
> OK so there is no reason for it not to work.
>
> > which produces:
> >
> > 2834 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2822
> >
> > cat /var/run/haproxy.pid then shows:
> > 2834
> >
> > I'll try manually sending SIGUSR1 and SIGTTOU as you suggested and see
> if I
> > can determine what's happening.
>
> Yes that will definitely help.
> >
> > Any chance that this issue is related to or that same as this one?
> >
> > https://github.com/haproxy/haproxy/issues/48
>
> Looks similar indeed. RHEL has selinux enabled by default I believe, I
>

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

 ❦ 30 octobre 2015 14:36 -0400, Chris Riley  :

> When the processes stack up, the old ones don't respond to anything
> other than 'kill -9'.

You could try to strace them to check where they currently are.
-- 
If more of us valued food and cheer and song above hoarded gold, it would
be a merrier world.
-- J.R.R. Tolkien

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

When the processes stack up, the old ones don't respond to anything other
than 'kill -9'.

On Fri, Oct 30, 2015 at 1:20 PM, Willy Tarreau  wrote:

> On Fri, Oct 30, 2015 at 12:23:57PM -0400, Chris Riley wrote:
> > Hi Willy,
> >
> > Thanks for your quick reply.
> >
> > > It should work better but will very likely hide the root cause. I
> suspect
> > > you'll find two processes running after a reload because the old one
> > > doesn't stop then.
> >
> > Yep, that's exactly what I'm seeing with 3.10. I've got a bunch of
> haproxy
> > processes stacked up, all with an -sf flag and each being passed the PID
> of
> > the previous process. The only one not in the process list is the initial
> > haproxy instance created when 'service haproxy start' was first run.
> >
> > lb-01 ~ [qa] # ps ax | grep hap
> >  2834 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2822
> >  2871 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2859
> >  2883 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2871
> >  2910 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2896
> >  2922 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2910
> >  2947 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2934
> >  2959 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2947
> >  2962 pts/1S+ 0:00 grep --colour=auto hap
>
> These ones don't all match, in fact only the last one is fine. That's
> strange.
>
> > > That would confirm the possibility that the signal is not sent at all,
> > > or at least not to the right process. Could you check the exact command
> > > that is started, to ensure the pids are correct (or present at all) ?
> > > Can you also try by hand to first send SIGUSR1 to the old process,
> > > then perform the reload, then send SIGTTOU by hand to the old one ?
> > > If it works, it would confirm an issue with the ability to send a
> > > signal to the old process from the new one.
> >
> > 'service haproxy start' invokes this:
> >
> > daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid
> >
> > which produces:
> >
> > usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
> >
> > ps ax shows:
> >
> > 2822 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid
> >
> > cat /var/run/haproxy.pid shows:
> > 2822
> >
> > 'service haproxy reload' invokes this:
> >
> > $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat
> > /var/run/$prog.pid)
>
> OK so there is no reason for it not to work.
>
> > which produces:
> >
> > 2834 ?Ss 0:00 /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg
> > -p /var/run/haproxy.pid -sf 2822
> >
> > cat /var/run/haproxy.pid then shows:
> > 2834
> >
> > I'll try manually sending SIGUSR1 and SIGTTOU as you suggested and see
> if I
> > can determine what's happening.
>
> Yes that will definitely help.
> >
> > Any chance that this issue is related to or that same as this one?
> >
> > https://github.com/haproxy/haproxy/issues/48
>
> Looks similar indeed. RHEL has selinux enabled by default I believe, I
> don't know if that could prevent haproxy from sending a signal to another
> process. Maybe you can try to stop it (if enabled at all).
>
> Regards,
> Willy
>
>

Re: Need some help configuring backend health checks