Failed requests with SC + NOSRV, threads
Hello, I have some rare requests with logs like: - Termination flags=SC - Server= - Retries=0 - Th=0 - Ti=10-50 (just normal values) - TR=0 - Other timings = -1 It happens in 2 cases 1. With remote backends, where it is probably a real problem (once for millions requests at average). - According to docs, means that request hasn't reached a server. How may it stay together with server's timeout-or-refuse flag? 2. With local backends, where 99% that it is haproxy's error (once for dozens thousands requests). - It must be a threads bug. I see it constantly when NBTHREAD is activated. Haproxy 1.8.9-1e3c84, lua -- Wert Revon
[PATCH] MINOR: tests: First regression testing file.
Hello,
Here is a simple patch to add a Makefile target to run all "*.vtc"
regression testing files found in 'reg-tests' directory.
It comes with a first VTC file in relation with f874a83 bug fix commit
for LUA. This VTC file parent directory is 'reg-tests/lua'.
I have copied and pasted the commit log at the beginning of the vtc
file. I think this would be a good practice so that to link the vtc
files to the bug it is supposed to test for any regression.
Regards,
Fred.
>From e05d7a9815c2b05e596740fb780e42c77931b6f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Mon, 18 Jun 2018 19:32:10 +0200
Subject: [PATCH] MINOR: tests: First regression testing file.
Add a makefile target 'reg-tests' to run all regression testing file
found in 'reg-tests' directory.
Add reg-tests/lua/h0.vtc first regression testing file for a LUA
fixed by f874a83 commit.
---
.gitignore | 1 +
Makefile | 5
reg-tests/lua/h0.lua | 3 ++
reg-tests/lua/h0.vtc | 74
4 files changed, 83 insertions(+)
create mode 100644 reg-tests/lua/h0.lua
create mode 100644 reg-tests/lua/h0.vtc
diff --git a/.gitignore b/.gitignore
index 73eaeae..32a8a84 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,6 +22,7 @@
!/tests
!/debian
!/scripts
+!/reg-tests
# Reject some generic files
*.o
*~
diff --git a/Makefile b/Makefile
index 5d17004..06f8ac9 100644
--- a/Makefile
+++ b/Makefile
@@ -996,3 +996,8 @@ update-version:
echo "$(VERSION)" > VERSION
echo "$(SUBVERS)" > SUBVERS
echo "$(VERDATE)" > VERDATE
+
+reg-tests:
+ @find reg-tests -type f -name "*.vtc" -print0 | \
+ xargs -0 $(VARNISHTEST_PROGRAM) -l -t5
+.PHONY: reg-tests
diff --git a/reg-tests/lua/h0.lua b/reg-tests/lua/h0.lua
new file mode 100644
index 000..d2401fa
--- /dev/null
+++ b/reg-tests/lua/h0.lua
@@ -0,0 +1,3 @@
+core.register_action("foo", { "http-req" }, function(txn)
+ txn.sc:ipmask(txn.f:src(), 24, 112)
+end)
diff --git a/reg-tests/lua/h0.vtc b/reg-tests/lua/h0.vtc
new file mode 100644
index 000..2b2ffb0
--- /dev/null
+++ b/reg-tests/lua/h0.vtc
@@ -0,0 +1,74 @@
+# commit f874a83
+# BUG/MINOR: lua: Segfaults with wrong usage of types.
+#
+# Patrick reported that this simple configuration made haproxy segfaults:
+#
+# global
+# lua-load /tmp/haproxy.lua
+#
+# frontend f1
+# mode http
+# bind :8000
+# default_backend b1
+#
+# http-request lua.foo
+#
+# backend b1
+# mode http
+# server s1 127.0.0.1:8080
+#
+# with this '/tmp/haproxy.lua' script:
+#
+# core.register_action("foo", { "http-req" }, function(txn)
+# txn.sc:ipmask(txn.f:src(), 24, 112)
+# end)
+#
+# This is due to missing initialization of the array of arguments
+# passed to hlua_lua2arg_check() which makes it enter code with
+# corrupted arguments.
+#
+# Thanks a lot to Patrick Hemmer for having reported this issue.
+
+
+varnishtest "Basic LUA test h0"
+feature ignore_unknown_macro
+
+server s1 -repeat 2 {
+rxreq
+txresp
+} -start
+
+haproxy h1 -conf {
+global
+lua-load ${testdir}/h0.lua
+
+frontend fe1
+mode http
+bind "fd@${fe1}"
+default_backend b1
+
+http-request lua.foo
+
+backend b1
+mode http
+server s1 ${s1_addr}:${s1_port}
+
+} -start
+
+client c0 -connect ${h1_fe1_sock} {
+txreq -url "/foo"
+rxresp
+expect resp.status == 200
+}
+
+client c1 -connect ${h1_fe1_sock} {
+txreq -url "/foo"
+rxresp
+expect resp.status == 200
+}
+
+client c0 -start
+client c1 -start
+
+client c0 -wait
+client c1 -wait
--
2.1.4
Re: Haproxy 1.8 rpm for CentOS 6
Yes, that's the plan :) Just need to know if there is any dependency on the system and haproxy version. On Mon 18 Jun, 2018, 10:03 PM Gibson, Brian (IMS), wrote: > You’d have to ask the standard repository maintainers for that answer. > IMO though it’s trivial to compile so if you need it why not just compile > it yourself? > > > > *From:* Vijay Bais [mailto:vija...@endurance.com] > *Sent:* Monday, June 18, 2018 12:28 PM > *To:* haproxy@formilux.org > *Subject:* Haproxy 1.8 rpm for CentOS 6 > > > > Hello, > > > > Is there a particular reason for no standard rpm available of haproxy-1.8 > on CentOS 6? > > > > Any inputs will be appreciate. > > > > Thanks, > > Vijay B > > -- > > Information in this e-mail may be confidential. It is intended only for > the addressee(s) identified above. If you are not the addressee(s), or an > employee or agent of the addressee(s), please note that any dissemination, > distribution, or copying of this communication is strictly prohibited. If > you have received this e-mail in error, please notify the sender of the > error. >
Re: Haproxy 1.8 rpm for CentOS 6
Full support of 6 ended in May, 2016 and Maint Support Lvl 1 ended May, 2017. It's now in the last period of retirement support, lvl 2... which does last until Nov, 2020, but updates are only going to be for very major security related things (and it's highly subjective). Most enterprise users will have already planned their migration away from 6 to be done around or shortly after May, 2016, but perhaps through end of lvl 1 Maint by May, 2017. Very little updating may occur in Lvl 2. Noting that Red Hat still offered Extended support of 6 (you have to pay) until June, 2024. Generally, speaking Red Hat wants you to migrate off 6 and the sooner, the better. CentOS roughly tracks with Red Hat since it's code updates come from them (in pretty much all cases). With that said, if a (out of band) package maintainer wanted to maintain their stuff through 2020 and beyond... up to them of course. On 06/18/2018 11:33 AM, Gibson, Brian (IMS) wrote: You’d have to ask the standard repository maintainers for that answer. IMO though it’s trivial to compile so if you need it why not just compile it yourself? *From:*Vijay Bais [mailto:vija...@endurance.com] *Sent:* Monday, June 18, 2018 12:28 PM *To:* haproxy@formilux.org *Subject:* Haproxy 1.8 rpm for CentOS 6 Hello, Is there a particular reason for no standard rpm available of haproxy-1.8 on CentOS 6? Any inputs will be appreciate. Thanks, Vijay B Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.
RE: Haproxy 1.8 rpm for CentOS 6
You’d have to ask the standard repository maintainers for that answer. IMO though it’s trivial to compile so if you need it why not just compile it yourself? From: Vijay Bais [mailto:vija...@endurance.com] Sent: Monday, June 18, 2018 12:28 PM To: haproxy@formilux.org Subject: Haproxy 1.8 rpm for CentOS 6 Hello, Is there a particular reason for no standard rpm available of haproxy-1.8 on CentOS 6? Any inputs will be appreciate. Thanks, Vijay B Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.
Haproxy 1.8 rpm for CentOS 6
Hello, Is there a particular reason for no standard rpm available of haproxy-1.8 on CentOS 6? Any inputs will be appreciate. Thanks, Vijay B
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
> On 18 Jun 2018, at 15:38, Emmanuel Hocdet wrote:
>
>
>> Le 18 juin 2018 à 15:30, Thierry Fournier a
>> écrit :
>>
>>
>>
>>> On 18 Jun 2018, at 14:37, Emmanuel Hocdet wrote:
>>>
Le 18 juin 2018 à 10:43, Thierry Fournier
a écrit :
> On 18 Jun 2018, at 10:33, Willy Tarreau wrote:
>
> On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org
> wrote:
>> Finally, I got it ! It works with luck because we have 1 bug in Haproxy
>> and 1 error (I suppose) in a OpenSSL compatibility layer.
> (...)
>> I join two patch. The first which fix the cipher capture must be
>> backported to 1.8, for the second patch wich fix the app data
>> compatibility, I dont known (at least 1.8).
>
> Good job! I imagine you didn't have a funny week-end playing with this
> one :-/
Yes, including the Friday :-) But I hope this path improve stability. If
someone
have time and is interested by the subject, it may be interesting to see
in the
OpenSSL code if the slot 0 used without reservation works fine, or works
because
we have luck.
>>>
>>> It work find because slot 0 is natively reserved for old *_{set,
>>> get}_app_data API compatibility.
>>
>>
>> Ok, thanks. So the classifcation BUG/MAJOR can be changed for BUG/MEDIUM
>> because it impacts only the usage of SSL join with the cipherlist hash.
>> Too late :-)
>>
>
> I think it should not be a bug at all (second patch), and set of ex_data
> without reservation
> (first patch and my patch) should be the only sources of bugs.
>
I don’t known. In fact it works, so it is not a bug. But, when I use the
reservation for an ex_data slot, it returns the slot 0, and this slot is
used for the compatibility layer and can be crush some data. I conclude
that is a bug in Openssl. The reservation function must give a slot
starting to 1.
Maybe, the recommendation is to not mix the compatibility functions
like set_app_data() with *ex_data*() functions. But, I don’t see
anything about this.
thierry
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
> Le 18 juin 2018 à 15:30, Thierry Fournier a
> écrit :
>
>
>
>> On 18 Jun 2018, at 14:37, Emmanuel Hocdet wrote:
>>
>>>
>>> Le 18 juin 2018 à 10:43, Thierry Fournier a
>>> écrit :
>>>
>>>
On 18 Jun 2018, at 10:33, Willy Tarreau wrote:
On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org
wrote:
> Finally, I got it ! It works with luck because we have 1 bug in Haproxy
> and 1 error (I suppose) in a OpenSSL compatibility layer.
(...)
> I join two patch. The first which fix the cipher capture must be
> backported to 1.8, for the second patch wich fix the app data
> compatibility, I dont known (at least 1.8).
Good job! I imagine you didn't have a funny week-end playing with this one
:-/
>>>
>>>
>>> Yes, including the Friday :-) But I hope this path improve stability. If
>>> someone
>>> have time and is interested by the subject, it may be interesting to see in
>>> the
>>> OpenSSL code if the slot 0 used without reservation works fine, or works
>>> because
>>> we have luck.
>>>
>>
>> It work find because slot 0 is natively reserved for old *_{set,
>> get}_app_data API compatibility.
>
>
> Ok, thanks. So the classifcation BUG/MAJOR can be changed for BUG/MEDIUM
> because it impacts only the usage of SSL join with the cipherlist hash.
> Too late :-)
>
I think it should not be a bug at all (second patch), and set of ex_data
without reservation
(first patch and my patch) should be the only sources of bugs.
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
> On 18 Jun 2018, at 14:37, Emmanuel Hocdet wrote:
>
>>
>> Le 18 juin 2018 à 10:43, Thierry Fournier a
>> écrit :
>>
>>
>>> On 18 Jun 2018, at 10:33, Willy Tarreau wrote:
>>>
>>> On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org
>>> wrote:
Finally, I got it ! It works with luck because we have 1 bug in Haproxy
and 1 error (I suppose) in a OpenSSL compatibility layer.
>>> (...)
I join two patch. The first which fix the cipher capture must be
backported to 1.8, for the second patch wich fix the app data
compatibility, I dont known (at least 1.8).
>>>
>>> Good job! I imagine you didn't have a funny week-end playing with this one
>>> :-/
>>
>>
>> Yes, including the Friday :-) But I hope this path improve stability. If
>> someone
>> have time and is interested by the subject, it may be interesting to see in
>> the
>> OpenSSL code if the slot 0 used without reservation works fine, or works
>> because
>> we have luck.
>>
>
> It work find because slot 0 is natively reserved for old *_{set,
> get}_app_data API compatibility.
Ok, thanks. So the classifcation BUG/MAJOR can be changed for BUG/MEDIUM
because it impacts only the usage of SSL join with the cipherlist hash.
Too late :-)
Thierry
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
> Le 18 juin 2018 à 10:43, Thierry Fournier a
> écrit :
>
>
>> On 18 Jun 2018, at 10:33, Willy Tarreau wrote:
>>
>> On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org
>> wrote:
>>> Finally, I got it ! It works with luck because we have 1 bug in Haproxy
>>> and 1 error (I suppose) in a OpenSSL compatibility layer.
>> (...)
>>> I join two patch. The first which fix the cipher capture must be
>>> backported to 1.8, for the second patch wich fix the app data
>>> compatibility, I dont known (at least 1.8).
>>
>> Good job! I imagine you didn't have a funny week-end playing with this one
>> :-/
>
>
> Yes, including the Friday :-) But I hope this path improve stability. If
> someone
> have time and is interested by the subject, it may be interesting to see in
> the
> OpenSSL code if the slot 0 used without reservation works fine, or works
> because
> we have luck.
>
It work find because slot 0 is natively reserved for old *_{set, get}_app_data
API compatibility.
++
Manu
Re: [PATCH] BUG/MEDIUM: ssl: do not store pkinfo with SSL_set_ex_data
On Mon, Jun 18, 2018 at 01:10:21PM +0200, Emmanuel Hocdet wrote: > > good catch! > > I see some strange things on my code now. I check that. > > > > I find one, and tag it MEDIUM because it could have random impact on ssl. > It's only for 1.9. Applied, thanks Manu! Willy
[PATCH] BUG/MEDIUM: ssl: do not store pkinfo with SSL_set_ex_data
> Le 18 juin 2018 à 11:49, Emmanuel Hocdet a écrit : > > > Hi Thierry, Willy > >> Le 18 juin 2018 à 10:43, Thierry Fournier a >> écrit : >> >> Yes, including the Friday :-) But I hope this path improve stability. If >> someone >> have time and is interested by the subject, it may be interesting to see in >> the >> OpenSSL code if the slot 0 used without reservation works fine, or works >> because >> we have luck. >> > > good catch! > I see some strange things on my code now. I check that. > I find one, and tag it MEDIUM because it could have random impact on ssl. It’s only for 1.9. ++ Manu 0001-BUG-MEDIUM-ssl-do-not-store-pkinfo-with-SSL_set_ex_d.patch Description: Binary data
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
Hi Thierry, Willy > Le 18 juin 2018 à 10:43, Thierry Fournier a > écrit : > > >> On 18 Jun 2018, at 10:33, Willy Tarreau wrote: >> >> On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org >> wrote: >>> Finally, I got it ! It works with luck because we have 1 bug in Haproxy >>> and 1 error (I suppose) in a OpenSSL compatibility layer. >> (...) >>> I join two patch. The first which fix the cipher capture must be >>> backported to 1.8, for the second patch wich fix the app data >>> compatibility, I dont known (at least 1.8). >> >> Good job! I imagine you didn't have a funny week-end playing with this one >> :-/ > > > Yes, including the Friday :-) But I hope this path improve stability. If > someone > have time and is interested by the subject, it may be interesting to see in > the > OpenSSL code if the slot 0 used without reservation works fine, or works > because > we have luck. > good catch! I see some strange things on my code now. I check that. ++ Manu
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
> On 18 Jun 2018, at 10:33, Willy Tarreau wrote: > > On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org wrote: >> Finally, I got it ! It works with luck because we have 1 bug in Haproxy >> and 1 error (I suppose) in a OpenSSL compatibility layer. > (...) >> I join two patch. The first which fix the cipher capture must be >> backported to 1.8, for the second patch wich fix the app data >> compatibility, I dont known (at least 1.8). > > Good job! I imagine you didn't have a funny week-end playing with this one :-/ Yes, including the Friday :-) But I hope this path improve stability. If someone have time and is interested by the subject, it may be interesting to see in the OpenSSL code if the slot 0 used without reservation works fine, or works because we have luck. BR, Thierry
Re: [PATCH] Re: Random crash (segfault, double free, ...) with a mix of SSL + cipherlist hash
On Sun, Jun 17, 2018 at 09:44:50PM +0200, thierry.fourn...@arpalert.org wrote: > Finally, I got it ! It works with luck because we have 1 bug in Haproxy > and 1 error (I suppose) in a OpenSSL compatibility layer. (...) > I join two patch. The first which fix the cipher capture must be > backported to 1.8, for the second patch wich fix the app data > compatibility, I dont known (at least 1.8). Good job! I imagine you didn't have a funny week-end playing with this one :-/ Now merged, thanks, Willy
Re: [PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.
On Sun, Jun 17, 2018 at 10:27:20PM +0200, Thierry Fournier wrote: > I read the ML too quicky, thiss is the right patch. OK applied, thanks guys. Willy
