make haproxy notice that backend server ip has changed

Hi, I'm running haproxy in ec2 environment - and there is one problem I noticed. The backend servers are configured as names and not ip - if backend server IP changes and even if the /etc/hosts on haproxy server is updated - haproxy does not catch this change. It has to be restarted to catch

Re: make haproxy notice that backend server ip has changed

). Are there other situations? CU, Jens On 04.08.2011, at 17:12, Piavlo wrote: Hi, I'm running haproxy in ec2 environment - and there is one problem I noticed. The backend servers are configured as names and not ip - if backend server IP changes and even if the /etc/hosts on haproxy server

Re: make haproxy notice that backend server ip has changed

On 08/05/2011 06:51 AM, Julien Vehent wrote: On Fri, 05 Aug 2011 01:08:22 +0300, Piavlo wrote: Hi Jens, I'm using names which resolve to internal EC2 addresses in haproxy configs - the /etc/hosts of all instances are auto updated then new instance is added/removed. But the problem manifests

Re: make haproxy notice that backend server ip has changed

On 08/05/2011 06:53 PM, Willy Tarreau wrote: On Fri, Aug 05, 2011 at 11:17:16AM +0300, Piavlo wrote: But why do a reload of haproxy in other situations (much more common in my use case and loose statistics and possibly some connections) if there could be a config option that tells haproxy

fallback of established tcp connections

Hi, There is a client which establishes a persistent tcp connection to the server, and haproxy in the middle which has a main server and backup server. Then main server goes offline , the connections are reestablished to the backup server just fine. The problem is that once main server is

Re: fallback of established tcp connections

Hi Willy, See comments below. On 10/08/2011 09:25 AM, Willy Tarreau wrote: Hi Alex, On Sun, Oct 02, 2011 at 06:44:43PM +0200, Piavlo wrote: Hi, There is a client which establishes a persistent tcp connection to the server, and haproxy in the middle which has a main server and backup

Re: avoiding CLOSE_WAIT on client side after client/server timeout

Hi Willy, On 10/08/2011 09:16 AM, Willy Tarreau wrote: Hi Alex, On Sun, Oct 02, 2011 at 06:48:08PM +0200, Piavlo wrote: Hi, I noticed that both for tcp and http connections then client/server timeout is reached and haproxy tears the connection - the client side socket is CLOSE_WAIT

appsession and stick-table relation

Hi, I'm using appsession for sticky sessions with one 1 hour timeout. I wonder if appsession has any internal relation to stick-table size? In particular is there any limit to the number of unique appsessions haproxy can store and if I can control it? ps. using version 1.4 Thanks Alex

Re: tracking maxconn between several haproxy server definitions - which correspond to same real web server

section? Thanks Alex cheers On Mon, Oct 31, 2011 at 7:40 PM, Cyril Bontécyril.bo...@free.fr wrote: Hi, Le Lundi 31 Octobre 2011 17:21:02 Piavlo a écrit : I have been using *capture cookie* and *appsession *in one haproxy configuration for sticky sessions. The problem is that then haproxy

all SET commands to haproxy socket fail with : Permission denied

Hi, Tried with several 1.4.* versions including latest, the get commands work and for set commands there is - Permission denied # echo get weight common_slave/slave1a | socat stdio /var/lib/haproxy/stats 25 (initial 25) # echo set weight common_slave/slave1a 50% | socat stdio

modifing default haproxy emit codes

Hi, According to the docs: Haproxy may emit the following status codes by itself : 503 when no server was available to handle the request, or in response to monitoring requests which match the monitor fail condition 504 when the response timeout strikes before the server

Re: modifing default haproxy emit codes

as an answer. Check the doc and come back here if you did not manage to configure it. Baptiste On Wed, Apr 2, 2014 at 9:16 PM, Piavlo lolitus...@gmail.com wrote: Hi, According to the docs: Haproxy may emit the following status codes by itself : 503 when no server was available to handle

haproxy stops responding to maskable signals

Then trying to gracefully reload haproxy often it fails to reload saying that it cannot bind to sockets. From what i see the old process does not close the listening sockets, and thus replacement process fails. Trying to send old haproxy process SIGTTOU and actualy any other maskable signal does