Re: freebsd ci is broken - commit 08fa16e - curl download stalls in reg-tests/compression/lua_validation.vtc

[Илья Шипицин]

ср, 15 янв. 2020 г. в 04:18, PiBa-NL :

> Hi Ilya, Willy,
>
> Op 14-1-2020 om 21:40 schreef Илья Шипицин:
> > PiBa, how many CPU cores are you running ?
> >
> > it turned out that I run tests on very low vm, which only has 1 core.
> > and tests pass.
> > cirrus-ci as far as I remember do have many cores.
> I was running with 16 cores..
> >
> > can you find single core vm ?
>
> Well, i reconfigured the VM to have 1 core, but same issue seems to show
> up, though not on every time the test is run, and actually a bit less
> often..
> Below some additional testresults with different kqueue / vCPU settings..
>

I run tests on MS Azure B1s vm, it is cheapest size. Single "shared" core.
Tests always pass.
looks like we've found race condition :)


>
>
> *VM with 1 vCPU*
>
> Running: ./vtest/VTest-master/vtest -Dno-htx=no -l -k -b 50M -t 5 -n 20
> ./work/haproxy-08fa16e/reg-tests/compression/lua_validation.vtc
>Results in: 4 tests failed, 0 tests skipped, 16 tests passed
>
> Adding "nokqueue" in the vtc file i get:
>8 tests failed, 0 tests skipped, 12 tests passed
>4 tests failed, 0 tests skipped, 16 tests passed
>
> So its a bit random, but the 'nokqueue' directive does not seem to
> affect results much..
>
>
> *With 16 vCPU*
> Without nokqueue: 16 tests failed, 0 tests skipped, 4 tests passed
> With nokqueue (using poll): 17 tests failed, 0 tests skipped, 3 tests
> passed
>
> The failure rate seems certainly higher with many cores..
>
>
> * Using commit 0eae632 it works OK*
> Just to be sure i re-tested on 16 cores with 2.2-dev0-0eae632 but that
> does nicely pass: 0 tests failed, 0 tests skipped, 20 tests passed
>
> Regards,
> PiBa-NL (Pieter)
>
>

Re: freebsd ci is broken - commit 08fa16e - curl download stalls in reg-tests/compression/lua_validation.vtc

[PiBa-NL]

Hi Ilya, Willy,

Op 14-1-2020 om 21:40 schreef Илья Шипицин:

PiBa, how many CPU cores are you running ?

it turned out that I run tests on very low vm, which only has 1 core. 
and tests pass.

cirrus-ci as far as I remember do have many cores.

I was running with 16 cores..


can you find single core vm ?


Well, i reconfigured the VM to have 1 core, but same issue seems to show 
up, though not on every time the test is run, and actually a bit less 
often..

Below some additional testresults with different kqueue / vCPU settings..


*VM with 1 vCPU*

Running: ./vtest/VTest-master/vtest -Dno-htx=no -l -k -b 50M -t 5 -n 20 
./work/haproxy-08fa16e/reg-tests/compression/lua_validation.vtc

  Results in: 4 tests failed, 0 tests skipped, 16 tests passed

Adding "nokqueue" in the vtc file i get:
  8 tests failed, 0 tests skipped, 12 tests passed
  4 tests failed, 0 tests skipped, 16 tests passed

So its a bit random, but the 'nokqueue' directive does not seem to 
affect results much..



*With 16 vCPU*
Without nokqueue: 16 tests failed, 0 tests skipped, 4 tests passed
With nokqueue (using poll): 17 tests failed, 0 tests skipped, 3 tests passed

The failure rate seems certainly higher with many cores..


* Using commit 0eae632 it works OK*
Just to be sure i re-tested on 16 cores with 2.2-dev0-0eae632 but that 
does nicely pass: 0 tests failed, 0 tests skipped, 20 tests passed


Regards,
PiBa-NL (Pieter)

Re: freebsd ci is broken - commit 08fa16e - curl download stalls in reg-tests/compression/lua_validation.vtc

[Willy Tarreau]

Hi guys,

On Tue, Jan 14, 2020 at 08:02:51PM +0100, PiBa-NL wrote:
> Below a part of the output that the test generates for me. The first curl
> request seems to succeed, but the second one runs into a timeout..
> When compiled with the commit before 08fa16e 
> 

Ah, and unsurprizingly I'm the author :-/

I'm wondering why it only affects FreeBSD (very likely kqueue in fact, I
suppose it works if you start with -dk). Maybe something subtle escaped
me in the poller after the previous changes.

> Should i update to a newer FreeBSD version, or is it likely unrelated, and
> in need of some developer attention.. Do you (Willy or anyone), 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 somewhere, in the worst case I'll ask
Olivier for some help :-)

Thanks for the report!
Willy

Re: freebsd ci is broken - commit 08fa16e - curl download stalls in reg-tests/compression/lua_validation.vtc

[Илья Шипицин]

PiBa, how many CPU cores are you running ?

it turned out that I run tests on very low vm, which only has 1 core. and
tests pass.
cirrus-ci as far as I remember do have many cores.

can you find single core vm ?

ср, 15 янв. 2020 г. в 00:02, PiBa-NL :

> Hi Ilya,
>
> Thanks!
>
> Op 14-1-2020 om 07:48 schreef Илья Шипицин:
>
> Hello,
>
> since
>
> https://github.com/haproxy/haproxy/commit/08fa16e397ffb1c6511b98ade2a3bfff9435e521
>
> freebsd CI is red: https://cirrus-ci.com/task/5960933184897024
>
> I'd say "it is something with CI itself",  when I run the same tests
> locally on freebsd, it is green.
>
> Sadly i do get the same problem on my test server (version info below its
> version 11.1 is a bit outdated, but hasn't failed my before...).
>
>
> PiBa ?
>
>
> thanks,
> Ilya Shipitcin
>
> Below a part of the output that the test generates for me. The first curl
> request seems to succeed, but the second one runs into a timeout..
> When compiled with the commit before 08fa16e
> 
> it does not show that behaviour.. Current latest(24c928c) commit is still
> affected..
>
>  top  shell_out|  % Total% Received % Xferd  Average Speed
> TimeTime Time  Current
>  top  shell_out| Dload  Upload
> Total   SpentLeft  Speed
>  top  shell_out|\r  0 00 00 0  0  0
> --:--:-- --:--:-- --:--:-- 0\r100  418k0  418k0 0
> 1908k  0 --:--:-- --:--:-- --:--:-- 1908k
>  top  shell_out|  % Total% Received % Xferd  Average Speed
> TimeTime Time  Current
>  top  shell_out| Dload  Upload
> Total   SpentLeft  Speed
>  top  shell_out|\r  0 00 00 0  0  0
> --:--:-- --:--:-- --:--:-- 0\r100  141k0  141k0 0
> 284k  0 --:--:-- --:--:-- --:--:--  284k\r100  343k0  343k0
> 0   156k  0 --:--:--  0:00:02 --:--:--  156k\r100  343k0  343k
> 0 0   105k  0 --:--:--  0:00:03 --:--:--  105k\r100  343k0
> 343k0 0  81274  0 --:--:--  0:00:04 --:--:-- 81274\r100
> 343k0  343k0 0  65228  0 --:--:--  0:00:05 --:--:--
> 65240\r100  343k0  343k0 0  54481  0 --:--:--  0:00:06
> --:--:-- 34743\r100  343k0  343k0 0  46768  0 --:--:--
> 0:00:07 --:--:-- 0\r100  343k0  343k0 0  40968  0
> --:--:--  0:00:08 --:--:-- 0\r100  343k0  343k0 0
> 36452  0 --:--:--  0:00:09 --:--:-- 0\r100  343k0  343k
> 0 0  32830  0 --:--:--  0:00:10 --:--:-- 0\r100  343k0
> 343k0 0  29865  0 --:--:--  0:00:11 --:--:-- 0\r100
> 343k0  343k0 0  27395  0 --:--:--  0:00:12 --:--:--
> 0\r100  343k0  343k0 0  25297  0 --:--:--  0:00:13
> --:--:-- 0\r100  343k0  343k0 0  23500  0 --:--:--
> 0:00:14 --:--:-- 0\r100  343k0  343k0 0  23431  0
> --:--:--  0:00:15 --:--:-- 0
>  top  shell_out|curl: (28) Operation timed out after 15002
> milliseconds with 351514 bytes received
>  top  shell_out|Expecting checksum 4d9c62aa5370b8d5f84f17ec2e78f483
>  top  shell_out|Received checksum: da2d120aedfd693eeba9cf1e578897a8
>  top  shell_status = 0x0001
>  top  shell_exit not as expected: got 0x0001 wanted 0x
> *top  RESETTING after
> ./work/haproxy-08fa16e/reg-tests/compression/lua_validation.vtc
>
> Should i update to a newer FreeBSD version, or is it likely unrelated, and
> in need of some developer attention.. Do you (Willy or anyone), need more
> information from my side? Or is there a patch i can try to validate?
>
> Regards,
> PiBa-NL (Pieter)
>
>
> Yes im running a somewhat outdated OS here:
>   FreeBSD freebsd11 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul
> 21 02:08:28 UTC 2017
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
> Version used:
>   haproxy -vv
> HA-Proxy version 2.2-dev0-08fa16e 2020/01/08 - https://haproxy.org/
> Status: development branch - not safe for use in production.
> Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
> Build options :
>   TARGET  = freebsd
>   CPU = generic
>   CC  = cc
>   CFLAGS  = -pipe -g -fstack-protector -fno-strict-aliasing
> -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
> -fno-strict-overflow -Wno-null-dereference -Wno-unused-label
> -Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers
> -Wno-unused-command-line-argument -Wno-missing-field-initializers
> -Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS
>   OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_REGPARM=1 USE_STATIC_PCRE=1
> USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=1
>
> Feature list : -EPOLL +KQUEUE -MY_EPOLL -MY_SPLICE -NETFILTER +PCRE
> +PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
> 

Re: freebsd ci is broken - commit 08fa16e - curl download stalls in reg-tests/compression/lua_validation.vtc

[PiBa-NL]

Hi Ilya,

Thanks!

Op 14-1-2020 om 07:48 schreef Илья Шипицин:

Hello,

since
https://github.com/haproxy/haproxy/commit/08fa16e397ffb1c6511b98ade2a3bfff9435e521

freebsd CI is red: https://cirrus-ci.com/task/5960933184897024

I'd say "it is something with CI itself",  when I run the same tests 
locally on freebsd, it is green.
Sadly i do get the same problem on my test server (version info below 
its version 11.1 is a bit outdated, but hasn't failed my before...).


PiBa ?


thanks,
Ilya Shipitcin


Below a part of the output that the test generates for me. The first 
curl request seems to succeed, but the second one runs into a timeout..
When compiled with the commit before 08fa16e 
 
it does not show that behaviour.. Current latest(24c928c) commit is 
still affected..


 top  shell_out|  % Total    % Received % Xferd  Average Speed   
Time    Time Time  Current
 top  shell_out| Dload Upload   
Total   Spent    Left  Speed
 top  shell_out|\r  0 0    0 0    0 0  0 0 --:--:-- 
--:--:-- --:--:-- 0\r100  418k    0  418k    0 0  1908k  0 
--:--:-- --:--:-- --:--:-- 1908k
 top  shell_out|  % Total    % Received % Xferd  Average Speed   
Time    Time Time  Current
 top  shell_out| Dload Upload   
Total   Spent    Left  Speed
 top  shell_out|\r  0 0    0 0    0 0  0 0 --:--:-- 
--:--:-- --:--:-- 0\r100  141k    0  141k    0 0   284k  0 
--:--:-- --:--:-- --:--:--  284k\r100  343k    0 343k    0 0   
156k  0 --:--:--  0:00:02 --:--:-- 156k\r100  343k    0  343k    
0 0   105k  0 --:--:-- 0:00:03 --:--:--  105k\r100  343k    0  
343k    0 0 81274  0 --:--:--  0:00:04 --:--:-- 81274\r100  
343k    0 343k    0 0  65228  0 --:--:--  0:00:05 --:--:-- 
65240\r100  343k    0  343k    0 0  54481  0 --:--:-- 0:00:06 
--:--:-- 34743\r100  343k    0  343k    0 0 46768  0 --:--:--  
0:00:07 --:--:-- 0\r100  343k    0 343k    0 0  40968  0 
--:--:--  0:00:08 --:--:-- 0\r100  343k    0  343k    0 0  
36452  0 --:--:--  0:00:09 --:--:-- 0\r100  343k    0  343k    
0 0  32830  0 --:--:--  0:00:10 --:--:-- 0\r100  343k    0  
343k    0 0 29865  0 --:--:--  0:00:11 --:--:-- 0\r100  
343k    0 343k    0 0  27395  0 --:--:--  0:00:12 --:--:-- 
0\r100  343k    0  343k    0 0  25297  0 --:--:--  0:00:13 
--:--:-- 0\r100  343k    0  343k    0 0  23500  0 --:--:--  
0:00:14 --:--:-- 0\r100  343k    0  343k    0 0 23431  0 
--:--:--  0:00:15 --:--:-- 0
 top  shell_out|curl: (28) Operation timed out after 15002 
milliseconds with 351514 bytes received

 top  shell_out|Expecting checksum 4d9c62aa5370b8d5f84f17ec2e78f483
 top  shell_out|Received checksum: da2d120aedfd693eeba9cf1e578897a8
 top  shell_status = 0x0001
 top  shell_exit not as expected: got 0x0001 wanted 0x
*    top  RESETTING after 
./work/haproxy-08fa16e/reg-tests/compression/lua_validation.vtc


Should i update to a newer FreeBSD version, or is it likely unrelated, 
and in need of some developer attention.. Do you (Willy or anyone), need 
more information from my side? Or is there a patch i can try to validate?


Regards,
PiBa-NL (Pieter)


Yes im running a somewhat outdated OS here:
  FreeBSD freebsd11 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri 
Jul 21 02:08:28 UTC 2017 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


Version used:
  haproxy -vv
HA-Proxy version 2.2-dev0-08fa16e 2020/01/08 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Build options :
  TARGET  = freebsd
  CPU = generic
  CC  = cc
  CFLAGS  = -pipe -g -fstack-protector -fno-strict-aliasing 
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-fno-strict-overflow -Wno-null-dereference -Wno-unused-label 
-Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers 
-Wno-unused-command-line-argument -Wno-missing-field-initializers 
-Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS
  OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_REGPARM=1 USE_STATIC_PCRE=1 
USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=1


Feature list : -EPOLL +KQUEUE -MY_EPOLL -MY_SPLICE -NETFILTER +PCRE 
+PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD 
-PTHREAD_PSHARED +REGPARM +STATIC_PCRE -STATIC_PCRE2 +TPROXY 
-LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT -CRYPT_H -VSYSCALL +GETADDRINFO 
+OPENSSL +LUA -FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY -TFO 
-NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER 
-PRCTL -THREAD_DUMP -EVPORTS


Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support 

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Tim Düsterhus]

Willy,

Am 14.01.20 um 14:53 schrieb Willy Tarreau:
> On Tue, Jan 14, 2020 at 02:04:04PM +0100, Thierry Fournier wrote:
>> Idea 1:
>>
>>lua-prepend-path path /etc/haproxy/lua-modules/?.lua
>>lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua
>>
>> Idea 2:
>>
>>lua-prepend-path /etc/haproxy/lua-modules/?.lua
>>lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua
>>
>> Idea 3:
>>
>>lua-prepend-path /etc/haproxy/lua-modules/?.lua
>>lua-prepend-cpath /etc/haproxy/lua-cmodules/?.lua
> 
> I guess the third one is better, at least for a reason which is that
> it causes less confusion when asking a bug reporter "what's in your
> lua-prepend-path ?". We've seen sufficient confusion from the maxconn
> word being used for different tihngs depending on where it's set, so
> we'd rather keep this clear.

Let me give my reasoning for my choice:

- I wanted to avoid two completely distinct configuration options for
what is essentially the same thing. It would require adding both to the
documentation.
- I made the type optional, because I expect the majority of modules
loaded via this option to be pure Lua modules. The path is meant to be
the home of HAProxy specific modules. I consider it unlikely for an user
to develop a C based Lua module that is HAProxy specific when they can
simply use a regular C based HAProxy module without corkscrewing it
through Lua. Stuff such as cjson would be put into the system wide Lua
path and thus be available to every Lua script including HAProxy,
because it sits in the default path that is compiled into the Lua VM.
- I put the type last, because I consider optional parameters that are
in the middle to be unintuitive and it complicates parsing, because a
single index might either be the type or the path if the type is not given.

However I don't particularly care for any of this. If you feel like we
should to lua-prepend-path and lua-prepend-cpath instead then I'm happy
to adjust the patch (or you do it).

Best regards
Tim Düsterhus

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Tim Düsterhus]

Thierry,

Am 14.01.20 um 14:04 schrieb Thierry Fournier:
> Just a little remark, I hope without consequences. Lua C libraries
> are .so and not .lua:
> 
>lua-prepend-path /etc/haproxy/lua-cmodules/?.lua cpath
> 
> becomes:
> 
>lua-prepend-path /etc/haproxy/lua-cmodules/?.so cpath
> 

Of course. That just was a copy and paste mistake within my cover letter
of the new patch series. You can specify arbitrary paths with arbitrary
file extensions. The implementation prepends the path as specified
within the configuration option.

Best regards
Tim Düsterhus

2020 RSA Conference

[stella D'souza]

I had a chance to review your company profile and thought you might be
interested in acquiring an Attendees list of RSA Conference 2020.

 

Just pick the number that describes best of your response. 
1. Send Expense and Counts. 
2. I'm not interested.

 

Delivery: MS Excel spread sheet within 24hrs on receipt of payment.

Let me know?

Best Regards!
Stella D'souza

Re: Lua: forcing garbage collector after socket i/o

[Dave Chiluk]

Can we get this backported onto the 2.0 and 1.9 stable streams?  It
looks like it mostly cleanly patches. *(aside from line numbers).

Thanks,
Dave

On Tue, Jan 14, 2020 at 3:49 AM Willy Tarreau  wrote:
>
> On Mon, Jan 13, 2020 at 10:11:57AM -0800, Sadasiva Gujjarlapudi wrote:
> > Sounds good to me.
> > Thank you so much once again.
>
> OK now merged. Thanks guys!
>
> Willy
>

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Willy Tarreau]

On Tue, Jan 14, 2020 at 02:04:04PM +0100, Thierry Fournier wrote:
> Idea 1:
> 
>lua-prepend-path path /etc/haproxy/lua-modules/?.lua
>lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua
> 
> Idea 2:
> 
>lua-prepend-path /etc/haproxy/lua-modules/?.lua
>lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua
> 
> Idea 3:
> 
>lua-prepend-path /etc/haproxy/lua-modules/?.lua
>lua-prepend-cpath /etc/haproxy/lua-cmodules/?.lua

I guess the third one is better, at least for a reason which is that
it causes less confusion when asking a bug reporter "what's in your
lua-prepend-path ?". We've seen sufficient confusion from the maxconn
word being used for different tihngs depending on where it's set, so
we'd rather keep this clear.

Thanks,
Willy

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Thierry Fournier]

> On 14 Jan 2020, at 13:53, Willy Tarreau  wrote:
> 
> On Tue, Jan 14, 2020 at 01:46:55PM +0100, Thierry Fournier wrote:
>> Hi, It have two default path in the library path:
>> 
>> - path for lua libraries
>> - cpath for loading lua C libraries.
>> 
>> In some cases, haproxy requires C libraries like cjson which manipulates 
>> json.
>> 
>> I'm not sure, but it seems that the patch "lua-prepend-path" doesn't include 
>> the cpath.
> 
> Yes it does now with an optional "cpath" keyword on the line. Maybe it's
> not the most convenient way and you'd prefer separate keywords ?


Sorry, I don’t see the keyword "cpath". Maybe a lua-prepend-cpath
would be clearer than a final keyword ? I don’t known. Maybe the
cpath word would be specified at the start in place of the end ?
The most important it was the cpath was taken in account !

Just a little remark, I hope without consequences. Lua C libraries
are .so and not .lua:

   lua-prepend-path /etc/haproxy/lua-cmodules/?.lua cpath

becomes:

   lua-prepend-path /etc/haproxy/lua-cmodules/?.so cpath




Idea 1:

   lua-prepend-path path /etc/haproxy/lua-modules/?.lua
   lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua

Idea 2:

   lua-prepend-path /etc/haproxy/lua-modules/?.lua
   lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua

Idea 3:

   lua-prepend-path /etc/haproxy/lua-modules/?.lua
   lua-prepend-cpath /etc/haproxy/lua-cmodules/?.lua

Thierry

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Willy Tarreau]

On Tue, Jan 14, 2020 at 01:46:55PM +0100, Thierry Fournier wrote:
> Hi, It have two default path in the library path:
> 
>  - path for lua libraries
>  - cpath for loading lua C libraries.
> 
> In some cases, haproxy requires C libraries like cjson which manipulates json.
> 
> I'm not sure, but it seems that the patch "lua-prepend-path" doesn't include 
> the cpath.

Yes it does now with an optional "cpath" keyword on the line. Maybe it's
not the most convenient way and you'd prefer separate keywords ?

Willy

Re: [PATCH v2 0/3] MINOR: lua: Add lua-prepend-path configuration option

[Thierry Fournier]

> On 14 Jan 2020, at 07:08, Willy Tarreau  wrote:
> 
> On Sun, Jan 12, 2020 at 01:55:38PM +0100, Tim Duesterhus wrote:
>> Willy,
>> Thierry,
>> Vincent,
>> 
>> I've just prepared a new version of my proposal with the following 
>> differences:
>> 
>> 1. I adjusted the documentation as suggested by Willy.
>> 2. I added support for `package.cpath` as suggested by Thierry.
>> 3. I added a build time option to be used by distros as suggested by Vincent.
> (...)
> 
> Thanks Tim! Thierry, just let me know if you think it's OK for merging
> and I'll handle it, or if you need more time to review it or are still
> having any doubts.
> 


Hi, It have two default path in the library path:

 - path for lua libraries
 - cpath for loading lua C libraries.

In some cases, haproxy requires C libraries like cjson which manipulates json.

I’m not sure, but it seems that the patch “lua-prepend-path” doesn’t include 
the cpath.

Thierry

Re: Lua: forcing garbage collector after socket i/o

[Willy Tarreau]

On Mon, Jan 13, 2020 at 10:11:57AM -0800, Sadasiva Gujjarlapudi wrote:
> Sounds good to me.
> Thank you so much once again.

OK now merged. Thanks guys!

Willy