Hi all,
În ziua de miercuri, 18 mai 2016, la 20:51:13 EEST, Willy Tarreau a scris:
> Thanks Vincent!
>
> It looks pretty good and very clean in the end.
> Arthur, as soon as you confirm it works for you I'll merge it. I'm keeping
> it untouched below in case you missed it.
Something seems a bit
În ziua de miercuri, 18 mai 2016, la 22:38:45 EEST, Cyril Bonté a scris:
> It looks like you didn't recompile with USE_OPENSSL=1
> haproxy -vv should give some hints.
Indeed, sorry about that. And error on my build script.
I fixed that, haproxy starts successfully but the issue remains, it still
Hi,
În ziua de miercuri, 18 mai 2016, la 22:58:06 EEST, Cyril Bonté a scris:
> Le 18/05/2016 22:52, Arthur Țițeică a écrit :
> > În ziua de miercuri, 18 mai 2016, la 22:38:45 EEST, Cyril Bonté a scris:
> >> It looks like you didn't recompile with USE_OPENSSL=1
> >> h
Hi,
With the 1.6.5 upgrade I see that a configuration like this
listen tcp-imap
bind 1.2.3.4:143name imap-v4
will make haproxy listen on all ipv4 addresses instead.
# ss -ltnp | column -t| grep 143
LISTEN 0 50 *:143 *:* users:(("haproxy",pid=13010,fd=19))
IPv6 works as
Hi,
1.6.4 worked fine with the same config.
I noticed this because I have the same port bound on 127.0.0.1 too and
haproxy refused to start after upgrade.
Another curious thing is that with haproxy bind on *two* ipv4 addresses I
also see two *:143 in the 'ss' output.
This is not specific to
I already went back and forth between the 2 versions to confirm that it's
still working fine in 1.6.4.
When I get home I will try to start haproxy in debug mode and I will try to
strace it (any help on this would be appreciated).
If all fails I will reboot the server in a non-grsec kernel (4.5.2
În ziua de miercuri, 18 mai 2016, la 10:30:56 EEST, Willy Tarreau a scris:
> That works for me. Let's have Arthur test them to confirm the issue goes
> away for him.
I'm glad to help.
În ziua de vineri, 13 mai 2016, la 19:12:23 EEST, Willy Tarreau a scris:
> On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> > I already went back and forth between the 2 versions to confirm that it's
> > still working fine in 1.6.4.
>
> But using a version that you rebuilt for
În ziua de vineri, 13 mai 2016, la 23:47:07 EEST, Willy Tarreau a scris:
> On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > > In the mean time, there may be a -fsomething option to disable a
> > > bogus optimization which causes this, but that's not easy to spot
> > > as it will
În ziua de sâmbătă, 14 mai 2016, la 13:57:35 EEST, Willy Tarreau a scris:
> On Sat, May 14, 2016 at 02:36:39PM +0300, Arthur ??i??eic?? wrote:
> > În ziua de vineri, 13 mai 2016, la 23:47:07 EEST, Willy Tarreau a scris:
> > > On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > > > >
Hello,
Thank you for taking the time to answer in detail.
În ziua de vineri, 10 noiembrie 2017, la 18:24:09 EET, Willy Tarreau a scris:
> On Fri, Nov 10, 2017 at 06:05:06PM +0200, Arthur Titeica wrote:
> > If this doesn't work is there some other mechanism to achieve something
> > like this?
>
Hello,
I'm trying to understand if the redispatch option may be used to retry a HTTP
connection in the following scenario:
Suppose there are multiple backend web servers and the first one that gets
chosen has a problem and replies with a 4xx or 5xx http status code.
Will the connection be
12 matches
Mail list logo
