Make it clear that tune.lua.maxmem expects a number.
---
doc/configuration.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 8b7f4aa19..f7e1ee6be 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -3137,7
for, but in the past they used
> to remain present while in idle state, using all the resources between
> two requests).
>
That's it. I was indeed NOT using HTX in 2.0. Thanks for the explanation.
Olivier
. I did not make any
change on keep alive or timeouts, that's why I'm wondering if any
modifications between 2.0 and 2.4 may explain this behaviour.
Cheers,
Olivier
d the counters, but do not expose them for requests yet, as I'm
> > unsure where to do that exactly, but that can easily be addressed with a
> > separate commit.
>
> Yes we can have a look later. I think we'll add new metric in the stats
> that will appear in a new tooltip on the b
Hi,
On Tue, Apr 04, 2023 at 09:45:24PM +0200, Willy Tarreau wrote:
> Hi Olivier,
>
> On Tue, Apr 04, 2023 at 12:29:15AM +0200, Olivier Houchard wrote:
> > Hi,
> >
> > The attached patchset is a first attempt at adding the possibility to
> > compre
requests, "response" if you want to compress
responses or "both", if you want to compress both.
The default is to compress responses only.
Any comment is more than welcome.
Thanks!
Olivier
>From 6c3e62baa888359521091387ce6ac8376a001259 Mon Sep 17 00:00:00 2001
From: Olivi
/backend. It will help me to know which one is it. Any "gdb" advice
how to narrow the issue down ?
Thanks,
Olivier
ble to have a NULL
> mux here in an idle connection since they're placed there by the muxes
> themselves. But maybe there's a tiny race somewhere that's impossible to
> reach except under such an extreme contention between the two sockets.
> I really have no idea regarding this on
e problem comes from OpenBSD's thread implementation, I
fear you may have too much contention in the kernel, especially on a
NUMA machine such as yours. Does using, say, only 4 threads, make things
better?
Regards,
Olivier
t;
I tried
http-request deny deny_status 405 if { url_sub -i "\$\{jndi:" or
hdr_sub(user-agent) -i "\$\{jndi:" }
and
http-request deny deny_status 405 if { url_sub -i ${jndi: or
hdr_sub(user-agent) -i ${jndi: }
without success. Can anyone tell what's wrong with both syntaxes ? And how
to escape special chars correctly ?
Olivier
"\$\{jndi:" }
What do you think ?
Olivier
st' layer 4/5/6/7 rules */
> cfgerr += check_action_rules(>tcp_req.l4_rules,
> curproxy, _code);
> cfgerr += check_action_rules(>tcp_req.l5_rules,
> curproxy, _code);
Your patch has been committed as feeccc6e40e4d61b1e9fa84aca961aceabe39371
Thanks a lot !
Olivier
you are totally correct, and this is the right thing to do. That
block is unrelated to the other changes in that commit, and probably
should not have been removed.
Regards,
Olivier
dont understand it
correctly and the hundreds of simultaneous streams in a single http2
connection triggers the limit ?
Any hint would help to understand what's happening here. It's difficult as
I don't have direct access to rules or the website of course :)
Olivier
is not
> > > already completed when you evaluate the rule, and of course you need
> > > to make sure the client sends using early data. I don't remember how
> > > Olivier used to run his tests but I remember that it was a bit tricky,
> > > so it's very possible that
don't know how to handle that properly. Willy, I think Dmitry's
solution of using the old builtins for clang/i386 might be the less
intrusive way of fixing it.
> PS: with that patch applied I get the following warning which can have sense:
>
> src/stick_table.c:3462:12: warning: result of comparison 'unsigned long' >
> 4294967295 is always false [-Wtautological-type-limit-compare]
> val > 0x)
> ~~~ ^ ~~
>
This one sounds mostly harmless, I guess whe should use a long long
here, and strtoull().
Olivier
ers with it, and it worked because headers are merged and
final behaviour matches what I was expecting.
Thank you !
Olivier
Hello,
Le jeu. 28 mai 2020 à 09:17, Willy Tarreau a écrit :
> http-request del-header range if { req.hdr_cnt(range) gt 1 }
>
This will only filter if header "Range" is present multiple times, not this
one :
Range: bytes=0-,0-,0-,0-
Am I correct ?
Olivier
w, then stop (for no reason), then triggers again.
And the config file contains ~ 1000 certificates...
It did not trigger before upgrade to 2.0.14 (I was using 2.0.13 before).
let me know if I can dig into some of the coredump to provide any useful
information.
Olivier
NS=
Built with OpenSSL version : OpenSSL 1.1.1g 21 Apr 2020
Olivier
Hi again,
Le mer. 6 mai 2020 à 17:47, Willy Tarreau a écrit :
> Hi Olivier,
>
> On Wed, May 06, 2020 at 05:29:59PM +0200, Olivier D wrote:
> > > Try applying this commit:
> > >
> > >
> https://github.com/haproxy/haproxy/commit/02c88036a61e09d0676a2b6b408
Hello,
Le mer. 6 mai 2020 à 15:30, Tim Düsterhus a écrit :
> Olivier,
>
> > I was not aware there were any change in the way HAProxy was doing its
> > checks over proxy-protocol in 2.0.14 ... any hint ?
>
> This sounds like this issue we've seen with Dovecot:
> h
Hello,
This morning I tried to upgrade HAProxy 2.0.13 to 2.0.14 but had to
rollback immediately : some backends checks started to fail.
Error reported was : SOCKERR - SSL handshake failure
The backends failing have a specific configuration as follows (I removed
anything unnecessary to trigger
is happens :(
Thank you !
Olivier
efinition :)
Your patch is now applied, thanks !
Olivier
On Sat, May 02, 2020 at 10:23:05PM +0200, William Dauchy wrote:
> On Sat, May 02, 2020 at 10:17:01PM +0200, Olivier Houchard wrote:
> > If that's the only change you have for a v2, don't bother, I already
> > integrated it in what I plan to push :)
>
> ok, thanks a lot!
&g
ruct connection *, list);
> > + if (!conn)
> > + break;
>
> just realised I forgot:
> did_remove = 1;
>
> but will wait before sending a possible v2 with other feedbacks.
If that's the only change you have for a v2, don't bother, I already
integrated it in what I plan to push :)
Regards,
Olivier
Hi William,
On Sat, May 02, 2020 at 09:52:35PM +0200, William Dauchy wrote:
> Hello Olivier,
>
> The following patch is an attempt to fix a change of behavior we encounter
> following commit:
>
> 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections
Hi,
Le mar. 21 avr. 2020 à 12:56, Tim Düsterhus a écrit :
> Olivier,
>
> PS: Personal opinion, but I prefer quotes in replies to be shortened as
> much as possible, while still providing context. I don't want to scroll
> through kilobytes of stuff I've already seen :-)
>
Hello,
Le lun. 20 avr. 2020 à 20:37, Tim Düsterhus a écrit :
> Olivier,
>
> Am 20.04.20 um 20:03 schrieb Olivier D:
> > I'm using gmail so I add to attach patches and was not able to send them
> > directly. If format is wrong, tell me :)
> >
>
> Format look
Hello,
Find attached two small patches to improve documentation on "option
forwardfor" and "http-request set-src".
I'm using gmail so I add to attach patches and was not able to send them
directly. If format is wrong, tell me :)
Olivier
From efbc320861c9c5a43219983cfc10730
Le ven. 17 avr. 2020 à 20:49, Tim Düsterhus a écrit :
> Olivier,
>
> Am 17.04.20 um 20:22 schrieb Olivier D:
> > My first tries are based on something like this :
> >stick-table type ipv6 size 100k expire 30s store http_req_rate(10s)
> Not sure whether that's jus
30s store http_req_rate(10s)
http-request track-sc0 req.hdr( X-Forwarded-For )
http-request deny deny_status 429 if { sc0_conn_cur ge 20 }
but it doesn't seem to work the way I want ...
Now I'm a bit lost, but maybe someone already implemented this ?
Thank you !
Olivier
On Fri, Mar 27, 2020 at 04:32:21PM +0100, Christian Ruppert wrote:
> On 2020-03-27 16:27, Olivier Houchard wrote:
> > On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
> >> During the reload I just found something in the daemon log:
> >> Mar 27 13
hanging
around ? Do you use seemless reload ? If so, it shouldn't attempt to
bind the socket, but get them from the old process.
Regards,
Olivier
you still have the TCP stat socket working, can you show the output
of "show fd" ?
Thanks !
Olivier
Hi Willy,
On Wed, Mar 25, 2020 at 02:03:56PM +0100, Willy Tarreau wrote:
> On Wed, Mar 25, 2020 at 12:40:33PM +0100, Olivier Houchard wrote:
> > I think I figured it out, and commit
> > 69664419d209d2f64dbcd90f991e7ec2efff2ee2
> > should fix it, at least now I can d
Hi Pieter,
On Wed, Mar 25, 2020 at 01:42:14AM +0100, Olivier Houchard wrote:
> Hi Pieter,
>
> On Wed, Mar 25, 2020 at 01:14:46AM +0100, PiBa-NL wrote:
> > Hi List, Willy,
> >
> > Today i thought lets give v2.2-dev5 a try for my production environment ;).
> >
Regards,
> PiBa-NL (Pieter)
>
No answer yet, but I just tried to do a checkout of the FreeBSD svn tree
via haproxy, and it indeed doesn't work, it's a bit late right now, but
I'll have a look tomorrow :)
Regards,
Olivier
PASS
Available services : none
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
Olivier
2
> bit, 64 bit or both ? Just like "x86, x86_64" before that.
>
> Recently we started testing on ARM64 and so far it works great! Great job!
> Thank you!
>
I guess this was written before arm64 was really a thing, but both 32bits
and 64bits arm are actively supported.
Regards,
Olivier
Le mer. 19 févr. 2020 à 16:24, Christopher Faulet a
écrit :
> Le 19/02/2020 à 16:05, Olivier D a écrit :
> > A bug was fixed in 2.0.12 that could explain such of crashes. The
> upstream
> > commit id is eec7f8ac0 (or 0ed1e8963 in the 2.0 tree). It is related
> to the
Hello,
Le mer. 19 févr. 2020 à 15:27, Christopher Faulet a
écrit :
> Le 19/02/2020 à 11:35, Olivier D a écrit :
> > Hello,
> >
> > I would like to report a segfault on HAProxy 2.0.11 ; this version has
> been
> > running fine for two months, and this morning starti
] compression
[CACHE] cache
[TRACE] trace
Config file is very long ... If needed, a coredump + binary can be sent on
private.
Olivier
yone), need more
> > information from my side? Or is there a patch i can try to validate?
>
> I don't think I need more info for now and your version has nothing to do
> with this (until proven otherwise). I apparently really broke something
> there. I think I have a FreeBSD VM
Hello,
Le mar. 17 déc. 2019 à 11:11, Willy Tarreau a écrit :
> Hi Olivier,
>
> On Tue, Dec 17, 2019 at 09:20:21AM +0100, Olivier D wrote:
> > That's not what I was saying. I'm already using "show server state", and
> > that's exactly what leads me to hours of d
Hello Igor,
Le lun. 16 déc. 2019 à 23:41, Igor Cicimov
a écrit :
> Hi,
>
> On Tue, Dec 17, 2019 at 2:55 AM Olivier D wrote:
>
>> Hello,
>>
>> I found what was wrong : I was using "load-server-state-from-file" and
>> previous config file was u
Hello,
I found what was wrong : I was using "load-server-state-from-file" and
previous config file was using port 80 as server port.
It seems using this instruction loads previous server state but also
previous srv_port.
Is this an expected behaviour ?
Olivier
Le ven. 13 déc. 20
Hello all,
I struggle with what seemed a very easy config :
listen test:443
id 20609
bind-process 16
balance source
hash-type consistent
mode tcp
bind x.x.x.x:443
server s1 192.168.x.x:443 id 2158 check weight 5 send-proxy port 80
server s2 192.168.x.x:443 id 2168
d foo-unsecure2
bind 127.0.0.1:4321 ssl force-tls11
I dont want to use 'ssl-min-ver' or 'ssl-max-ver' because the config file
is auto-generated from a database, and it would make the code more
difficult.
Thank you for your feedback.
Olivier
",
'\000' "\350,
\024\203\331\262\177\000\000\200\nKi\377\177\000\000\035\000\000\000\000\000\000\000\230\nKi\377\177\000\000
\206\060\001\001\000\000\000\000v\000"
pidfd =
Config file is very heavy with dozens of frontends and backends.
I can provide the coredump in a secure channel if needed.
Olivier
ections, they ended up on 2 different threads, and so wouldn't reuse the
other connection. I'm not sure how you ran your test, but using "nbthread 1"
should make it reuse as you'd expect (or just having more frontend connections
than threads, at some point you should see some reuse).
Regards,
Olivier
d foo-unsecure2
bind 127.0.0.1:4321 ssl force-tls11
I dont want to use 'ssl-min-ver' or 'ssl-max-ver' because the config file
is auto-generated from a database, and it would make the code more
difficult.
Thank you for your feedback.
Olivier
On Wed, Aug 07, 2019 at 03:09:26PM +0200, Emmanuel Hocdet wrote:
> Hi,
>
> Two patches to fix (and simplify) 0-RTT for BoringSSL.
> If you can consider them.
>
> ++
> Manu
>
Applied, thanks !
Olivier
Hi Fred,
On Thu, Jul 04, 2019 at 02:37:55PM +0200, Frederic Lecaille wrote:
> On 7/4/19 1:36 PM, Olivier Houchard wrote:
> > Hi William,
> >
> > On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:
> > > Hello,
> > >
> > > On haproxy
on to disallow tfo on default-server, it was an
oversight, it is fixed in master with commit
8d82db70a5f32427fb592a947d2a612bcb01d95e, and should be backported in 2.0
before the next release.
Regards,
Olivier
pchk GET /check HTTP/1.1\r\nHost:\ server.local
> http-check send-state
> http-check expect status 200
> tcp-request inspect-delay 10s
> tcp-request content reject if { nbsrv lt 1 }
> default-server weight 50
> server backend-server.local:17995 backend-server.local:17995 check port
> 17994
>
What kind of requests do you do ? GET ? POST ? Others ?
Thanks !
Olivier
SL connection
before attempting to change the ALPN. This should be fixed by commit
c50eb73b85f80ac1ac6e519fcab2ba6807f5de65, and should be backported to 2.0
soon.
Thanks a lot !
Olivier
.git;a=commit;h=9eae8935663bc0b27c23018e8cc24ae9a3e31732
>
It is believed to be fixed in master, and should be backported to 2.0 soon.
If you feel like it, you can apply commit
0ff28651c184f2b6cc7782b0960ed69cc907ca97, and let me know if you still have
issues or not.
You may want c31e2cbd28d53210b7184091bb64137c806d7957 too.
Regards,
Olivier
Hi Igor,
On Sun, Jun 23, 2019 at 08:42:46PM +0800, Igor Pav wrote:
> Hi Olivier,
>
> The `retry-on 0rtt-rejected` will only work in tcp mode, is that
> possible to let it work in http mode too?
>
It should work with HTTP too. What may happen is you're using "alpn" on
Hi Igor,
On Sat, Jun 15, 2019 at 07:19:24PM +0800, Igor Pav wrote:
> Hi Olivier,
>
> Still suffering from 2.0-dev7-b6563f-41 :(
>
I can't seem to reproduce it.
I found a potential issue, and 965e84e2df7ba448d887bd5e9e03d76b206d3eee may
help.
If it does not, how do you reproduc
one
>
Indeed, it was not working as expected when specifying the ALPN. I believe
this is now fixed, can you confirm it ?
Thanks !
Olivier
if they are not necessarily present, let's not force :-)
>
> thanks guys for fueling the discussion.
>
> Willy
>
Sorry if I'm totally "out" on this point, but I was wondering why HAProxy
did not provide a simple "configure" script : all available options would
be listed (I know it's in the doc, but hey, how many people do actually
read it ? :p). and script will check if options chosen can be compiled (if
pcre2 is available, if openssl-devel is available, and so on ...).
You may then pick a default config, for example SSL always compiled in, LUA
not, ... if no other option are provided.
Olivier
On Thu, Jun 06, 2019 at 08:33:26PM +0200, PiBa-NL wrote:
> Hi Olivier,
>
> Op 6-6-2019 om 18:20 schreef Olivier Houchard:
> > Hi Pieter,
> >
> > On Wed, Jun 05, 2019 at 09:00:22PM +0200, PiBa-NL wrote:
> > > Hi Olivier,
> > >
> > > It seems
Hi Pieter,
On Wed, Jun 05, 2019 at 09:00:22PM +0200, PiBa-NL wrote:
> Hi Olivier,
>
> It seems this commit ea8dd94 broke something for my FreeBSD11 system.
> Before that commit (almost) all vtest's succeed. After it several cause
> core-dumps. (and keep doing that including t
Hi William,
On Wed, May 15, 2019 at 01:10:37PM +0200, William Dauchy wrote:
> Hello Olivier,
>
> In another subject related to 0rtt was wondering why it was not
> available in ssl-default-bind-options?
>
We usually only add options in ssl-default-bind-options that can lat
0}, recv_wait = 0x0, send_wait = 0x0, list = {n = 0x15b31a8, p =
> 0x15b31a8}, sending_list = {n = 0x15b31b8, p = 0x15b31b8}}
> (gdb) n
> 2609list_for_each_entry_safe(h2s, h2s_back, >send_list, list) {
> (gdb) n
> 2610 if (h2c->st0 >= H2_CS_ERROR || h2c->flags &
> H2_CF_MUX_BLOCK_ANY)
> (gdb) n
> 2609list_for_each_entry_safe(h2s, h2s_back, >send_list, list) {
> (gdb) n
> 2610if (h2c->st0 >= H2_CS_ERROR || h2c->flags &
> H2_CF_MUX_BLOCK_ANY)
> (gdb) n
> 2609list_for_each_entry_safe(h2s, h2s_back, >send_list, list) {
> (gdb) n
> 2613if (!LIST_ISEMPTY(>sending_list))
> (gdb) n
> 2619if (!h2s->send_wait) {
> (gdb) n
> 2620LIST_DEL_INIT(>list);
> (gdb) n
> 2609list_for_each_entry_safe(h2s, h2s_back, >send_list, list) {
> (gdb) n
> 2610if (h2c->st0 >= H2_CS_ERROR || h2c->flags &
> H2_CF_MUX_BLOCK_ANY)
>
Thanks a lot, this is really helpful !
I just pushed bcf3e9c622baceb7aafc01d72e2dbb6992b872b8, and I think it
could help, any chance you can test it ?
Thanks !
Olivier
On Wed, May 08, 2019 at 02:30:07PM +0200, Willy Tarreau wrote:
> On Wed, May 08, 2019 at 01:56:05PM +0200, Olivier Houchard wrote:
> > > > One of processes stuck in infinite loop, admin socket is not responsive
> > > > so
> > >
.
> >
> > One of processes stuck in infinite loop, admin socket is not responsive so
> > I've got information only from gdb:
> >
> > 0x00484ab8 in h2_process_mux (h2c=0x2e8ff30) at src/mux_h2.c:2589
> > 2589if (h2s->send_wait->events &
://travis-ci.org/chipitsine/haproxy-1/builds/528535120
>
> thanks!
You're right indeed, it was definitively broken for libressl, it should be
fixed with commit 4cd2af4e5d785c42d2924492df987a7cd5832e23
Regards,
Olivier
Hi Igor,
On Mon, May 06, 2019 at 12:26:33AM +0800, Igor Pav wrote:
> Hi, Olivier, thanks for the effort. So can we force the server always
> to carry data to remote via 0RTT like below scenario(to protect
> http2http in unsecured env)?
>
> listen http -- server default x.x
ou add "allow-0rtt" on your server line. However it hasn't
been tested for some time, and was written with a development version of
OpenSSL 1.1.1, so I wouldn't be entirely surprised if it didn't work anymore.
Regards,
Olivier
|= src->flags;
> srv->do_check = src->do_check;
Oops, that seems right, it's been pushed, thanks a lot !
Olivier
e 100% of the CPU has been fixed in the HTTP/2
code just after the 1.9.7 release was done.
Any chance you can see if it still happens with that commit :
commit c980b511bfef566e9890eb9a06d607c193d63828
Author: Willy Tarreau
Date: Mon Apr 29 10:20:21 2019 +0200
BUG/MEDIUM: mux-h2: properly deal with too large headers frames
Regards,
Olivier
Hi,
On Fri, Apr 12, 2019 at 08:37:10AM +0200, Maciej Zdeb wrote:
> Hi Richard,
>
> Those patches from Olivier (in streams) are related to my report from
> thread "[1.9.6] One of haproxy processes using 100% CPU", but as it turned
> out it wasn't a single bug and issue
=-1 total=14)
> an_exp= rex=30s wex=
> buf=0x20eec408 data=0x20e2a530 o=0 p=0 req.next=0 i=0 size=16384
> res=0x20eec460 (f=0x80008002 an=0x0 pipe=0 tofwd=-1 total=1465)
> an_exp= rex= wex=
> buf=0x20eec468 data=0x20d5bbd0 o=1465 p=1465 rsp.next=0 i=0 size=16384
>
This is indeed very strange. I'm quite interested in seeing the output of
"show fd", as you mentionned you had it.
Thanks !
Olivier
how it may have happened, and hopefully fixed it with
commit to master 06f6811d9fc3f36597b686e4ca9fe7fbccf091b0
It will be backported to 1.9 later, but if you need it right now, you can
probably apply it on 1.9 as-is.
Thanks a lot for reporting !
Olivier
Hi David,
On Wed, Mar 27, 2019 at 04:13:28PM +, David CARLIER wrote:
> Hi Here a little patch proposal.
>
> Kind regards.
Sounds good ! I pushed it.
Thanks a lot !
Olivier
that as well.
Can you confirm that your problems are gone in master ?
Thanks a lot !
Olivier
Hi Patrick,
On Thu, Feb 14, 2019 at 09:12:18AM -0500, Patrick Hemmer wrote:
>
>
> On 2019/2/14 08:20, Frederic Lecaille wrote:
> > On 2/14/19 1:32 PM, Frederic Lecaille wrote:
> >> On 2/13/19 7:30 PM, Patrick Hemmer wrote:
> >>>
> >>>
> >&g
_INITCALL'
> >> __DECLARE_INITCALL(__VA_ARGS__)
> >> ^
> >> include/common/initcall.h:65:42: note: expanded from macro
> >> '__DECLARE_INITCALL'
> >>
> >> __att
Hello,
Le sam. 12 janv. 2019 à 13:19, Willy Tarreau a écrit :
> Hi Olivier,
>
> On Wed, Jan 09, 2019 at 07:23:42PM +0100, Olivier D wrote:
> > Hello folks,
> >
> > Just wanted to raise an issue with a compilation error on HAProxy that I
> > was able to sol
On Thu, Jan 17, 2019 at 03:09:20PM +, Luke Seelenbinder wrote:
> Hi Oliver,
>
> Yes! I can confirm the patch does indeed work—thanks for the quick turnaround.
>
> Best,
> Luke
>
Willy, can you push it ?
Thanks !
Olivier
>From 585bcc7f8ec84573d070d2d9d1e0b104fd18
isable h2 on the backend, it works correctly. If I disable the source
> in defaults, it works correctly. I've attached the backtrace below.
>
> Best,
> Luke
>
I think I understand what's going on.
Does the attached patch fix it for you ?
Thanks a lot !
Olivier
>From 585bcc7f8ec84573
r_check_status() is call, and the check's status and result
may be updated. Not sure it is really needed, but I'd rather not offend
the Check Gods.
The attached patches are updated to od just that.
Regards,
Olivier
>From 7e7b41cac480029c5fd93338dd86a875fee0b5a7 Mon Sep 17 00:00:00 2001
From: Ol
On Fri, Jan 11, 2019 at 06:53:11PM +0100, Olivier Houchard wrote:
> Hi,
>
> On Fri, Jan 11, 2019 at 10:36:04AM +0100, Johan Hendriks wrote:
> > Thanks all.
> > No rush on my side as it is a test machine, at least we do know when a
> > backend server fails.
> > W
r now.
>
> Thanks again Pieter, Willy and Oliver for all your work.
>
>
> Op 10-01-19 om 20:05 schreef PiBa-NL:
> > Hi Johan, Olivier, Willy,
> >
> > Op 10-1-2019 om 17:00 schreef Johan Hendriks:
> >> I just updated to 1.9.1 on my test system.
> >
... and compilation was OK !
I tried with gcc 4.8.2 (centos6) and gcc 7.2.1 with exactly the same
behaviour.
Additional softwares used :
OpenSSL 1.1.1a
Lua 5.3.5
PCRE version : 8.41
zlib version : 1.2.11
Olivier
Hi Willy,
On Tue, Jan 08, 2019 at 03:44:07PM +0100, Willy Tarreau wrote:
> On Tue, Jan 08, 2019 at 03:27:58PM +0100, Olivier Houchard wrote:
> > On Tue, Jan 08, 2019 at 03:00:32PM +0100, Janusz Dziemidowicz wrote:
> > > pt., 4 sty 2019 o 11:59 Olivier Houchard
> > >
> srv=0x22aeb60) at include/proto/server.h:244
> 244LIST_ADDQ(>idle_orphan_conns[tid], >list);
>
> (gdb) print >idle_orphan_conns[tid]
> $1 = (struct list *) 0x0
>
> (gdb) print >list
> $2 = (struct list *) 0x2331370
Oops, that seems right, and the patch looks fine, Willy can you push it ?
Thanks a lot !
Olivier
On Tue, Jan 08, 2019 at 03:00:32PM +0100, Janusz Dziemidowicz wrote:
> pt., 4 sty 2019 o 11:59 Olivier Houchard napisa??(a):
> > I understand the concern.
> > I checked and both nghttp2 and nginx disable the replay protection. The idea
> > is you're supposed to allow early
Hi Janusz,
On Fri, Jan 04, 2019 at 10:53:51AM +0100, Janusz Dziemidowicz wrote:
> czw., 3 sty 2019 o 17:52 Olivier Houchard napisa??(a):
> > Ah I think I figured it out.
> > OpenSSL added anti-replay protection when using early data, and it messes up
> > with
Hi Janusz,
On Thu, Jan 03, 2019 at 11:49:35AM +0100, Janusz Dziemidowicz wrote:
> ??r., 2 sty 2019 o 19:04 Olivier Houchard napisa??(a):
> > You're right indeed. 0RTT was added with a development version of OpenSSL
> > 1.1.1,
> > which had a default value for ma
hing.
>
> Is it supposed to work at all or do I miss something? ;)
>
You're right indeed. 0RTT was added with a development version of OpenSSL 1.1.1,
which had a default value for max early data of 16384, but it was changed to
0 in the meanwhile.
Does the attached patch work for you ?
Thanks !
s 3
> option redispatch 1
>
> frontend http-in
> bind :80
> default_backend mybak
>
> backend mybak
> mode http
> balance first
> server primary-fail 10.0.0.199:80 # this server is unreachable
> server backup-ok 10.0.0.254:80
>
>
>
>
On Thu, Nov 15, 2018 at 02:26:59PM +0100, Willy Tarreau wrote:
> On Thu, Nov 15, 2018 at 11:58:36AM +0100, Olivier Houchard wrote:
> > Willy, can you push the attached patch ?
>
> Applied, thanks. I've just slightly edited it to put parenthesis around
> "i" below :
&g
On Thu, Nov 15, 2018 at 09:48:20AM +, Paul Martin wrote:
> On Wed, Nov 14, 2018 at 06:05:00PM +0100, Olivier Houchard wrote:
>
> > Oops, you're right indeed.
> > I'm not sure I'm a big fan of special-casing STD_T_UINT. For example,
> > STD_T_FRQP is probably 12bytes t
ueing ("maxconn" on the server lines) or if you're seeing
> a lot of "server up/down" events.
>
> Thanks,
> Willy
Nice catch !
This one is a good candidate.
Regards,
Olivier
Hi Soji,
On Mon, Oct 15, 2018 at 11:10:09PM +0530, Soji Antony wrote:
> Hi Olivier,
>
> Many thanks for your reply.
> Please find the gdb output given below.
>
> # gdb /usr/sbin/haproxy core.dump3.13871
> GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
> Copyrigh
you could at least give use the gdb output
of "thread apply all bt" so that we know where each thread is spinning, that
may be very useful, and shouldn't leak any confidential information.
Thanks !
Olivier
> [image: Screen Shot 2018-10-12 at 8.13.02 PM.png]
>
> On Fri,
1 - 100 of 321 matches
Mail list logo
