Re: SD-termination cause
Hi Willy!
Sorry for bothering you, but do you have any news about this case?
чт, 23 мая 2019 г. в 10:35, Willy Tarreau :
> Hi Maksim,
>
> On Thu, May 23, 2019 at 10:00:19AM +0300, ?? ? wrote:
> > 2nd session (from haproxy to ssl-enabled backend A, dumped with tshark
> for
> > better readability):
> > 1 09:10:48.222518 HAPROXY -> BACKEND_A TCP 94 36568 -> 9790 [SYN] Seq=0
> > Win=26520 Len=0 MSS=8840 SACK_PERM=1 TSval=3064071282 TSecr=0 WS=2048
> > 2 09:10:48.222624 BACKEND_A -> HAPROXY TCP 94 9790 -> 36568 [SYN, ACK]
> Seq=0
> > Ack=1 Win=26784 Len=0 MSS=8940 SACK_PERM=1 TSval=3366865490
> > TSecr=3064071282 WS=256
> > 3 09:10:48.222639 HAPROXY -> BACKEND_A TCP 86 36568 -> 9790 [ACK] Seq=1
> Ack=1
> > Win=26624 Len=0 TSval=3064071283 TSecr=3366865490
> > 4 09:10:48.222658 HAPROXY -> BACKEND_A TLSv1 603 Client Hello
> > 5 09:10:48.222741 BACKEND_A -> HAPROXY TCP 86 9790 -> 36568 [ACK] Seq=1
> > Ack=518 Win=27904 Len=0 TSval=3366865490 TSecr=3064071283
> > 6 09:10:48.272165 HAPROXY -> BACKEND_A TCP 86 36568 -> 9790 [RST, ACK]
> > Seq=518 Ack=1 Win=26624 Len=0 TSval=3064071332 TSecr=3366865490
> >
> > Backend didn't answer with Server Hello in 49.5ms after tcp-handshed has
> > finished for some reason. That is the root case of the error!!!
>
> Indeed, this is an interesting case. I'm not sure why it's reported like
> this but it definitely is a corner case as the L4 connection is established
> and the handshake was aborted. It should have been reported as "sC"
> (timeout
> during connect). But I can easily understand how we can make some wrong
> assumptions based on the available elements when reporting an error (e.g.
> the connection is valid, only the handshake is incomplete). We definitely
> need to figure what's happening before releasing 2.0, as it could indicate
> a bigger issue in the connection setup error path. By the way I'm thinking
> that for 2.1 we should probably think about reporting a separate step for
> the server-side handshake, but that's another story.
>
> > The last session (from haproxy to plain-http backend B):
> > 1 09:10:48.272235 HAPROXY -> BACKEND_B TCP 94 33532 -> 9791 [SYN] Seq=0
> > Win=26520 Len=0 MSS=8840 SACK_PERM=1 TSval=561683483 TSecr=0 WS=2048
> > 2 09:10:48.272358 BACKEND_B -> HAPROXY TCP 94 9791 -> 33532 [SYN, ACK]
> Seq=0
> > Ack=1 Win=26784 Len=0 MSS=8940 SACK_PERM=1 TSval=874005989
> TSecr=561683483
> > WS=256
> > 3 09:10:48.272369 HAPROXY -> BACKEND_B TCP 86 33532 -> 9791 [ACK] Seq=1
> Ack=1
> > Win=26624 Len=0 TSval=561683483 TSecr=874005989
> > 4 09:10:48.272396 HAPROXY -> BACKEND_B HTTP 3590 GET /xx/xx/xxx
> > HTTP/1.1
> > 5 09:10:48.272448 HAPROXY -> BACKEND_B TCP 86 33532 -> 9791 [FIN, ACK]
> > Seq=3505 Ack=1 Win=26624 Len=0 TSval=561683483 TSecr=874005989
> > 6 09:10:48.272529 BACKEND_B -> HAPROXY TCP 86 9791 -> 33532 [ACK] Seq=1
> > Ack=3505 Win=33792 Len=0 TSval=874005989 TSecr=561683483
> > 7 09:10:48.272729 BACKEND_B -> HAPROXY TCP 86 9791 -> 33532 [FIN, ACK]
> Seq=1
> > Ack=3506 Win=33792 Len=0 TSval=874005989 TSecr=561683483
> > 8 09:10:48.272736 HAPROXY -> BACKEND_B TCP 86 33532 -> 9791 [ACK]
> Seq=3506
> > Ack=2 Win=26624 Len=0 TSval=561683484 TSecr=874005989
> >
> > As you can see, haproxy instance made another try to establish connection
> > and it did succeed but 50ms are over, and FIN was send right after
> > GET-request.
>
> This should never happen either, or you may quickly run out of source ports
> by having your ports in TIME_WAIT state :-(
>
> > Conclusion:
> > * Haproxy does not respond with 502 in case of timing out on
> ssl-connection
> > establishing to backends
>
> So for this case since it's a timeout, it should be a 504.
>
> > * Seems strange to me that connection timer was not reset after the first
> > unsuccessfull connection ("retries 1" was set)
>
> Indeed you're right, that might be the reason for the FIN just after
> the GET.
>
> > * SD-status of error is confusing :)
>
> I suspect there are in fact 2 or 3 issues in the outgoing connection
> code that result in all of this. This code is very complex since it
> has to deal with reuse, server pools and redispatch at the same time.
> We need to have a look into this. I'll wait for Olivier's availability
> since he knows this area better (especially the reuse stuff that I
> would break just by approaching it).
>
> Many thanks for your detailed traces and analysis, this is very
> informative!
>
> Willy
>
unset-var doesn't support conditions
It appears that all usages of unset-var don't support conditions.
Meaning none of the following work:
http-request unset-var(txn.foo) if { always_true }
tcp-request content unset-var(txn.foo) if { always_true }
etc.
The error presented is:
[ALERT] 153/175307 (58641) : parsing [haproxy-minimal.cfg:12] : error
detected in frontend 'f1' while parsing 'http-request
unset-var(txn.foo)' rule :
fetch method not supported.
[ALERT] 153/175307 (58641) : Error(s) found in configuration file :
haproxy-minimal.cfg
The documentation indicates this should be possible:
http-request unset-var() [ { if | unless } ]
This is experienced with version 1.9.8
-Patrick
segfault in tcp-request session set-var
In haproxy 1.9.8, if you do `tcp-request session set-var()` with a variable in any scope other than sess, it segfaults. For example: tcp-request session set-var(txn.foo) ... tcp-request session set-var(req.foo) ... * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x268) frame #0: 0x00010019c6a7 haproxy`sample_store_stream(name="foo", scope=SCOPE_TXN, smp=0x7ffeefbfef48) at vars.c:442 439 case SCOPE_RES: 440 default: vars = >strm->vars_reqres; break; 441 } -> 442 if (vars->scope != scope) 443 return 0; 444 445 HA_RWLOCK_WRLOCK(VARS_LOCK, >rwlock); Target 0: (haproxy) stopped. -Patrick
Re: http_first_req not working with http2
*From:* Patrick Hemmer [mailto:hapr...@stormcloud9.net] *Sent:* Monday, June 3, 2019, 17:21 EDT *To:* haproxy@formilux.org *Subject:* http_first_req not working with http2 As subject says, it appears that the http_first_req sample is not working with http2. Config: frontend f1 bind :8000 option http-use-htx log-format http_first_req=%[http_first_req] With `curl http://localhost:8000` Outputs: <30>Jun 3 17:16:36 haproxy[47767]: http_first_req=1 Where as, Config: frontend f1 bind :8000 proto h2 option http-use-htx log-format http_first_req=%[http_first_req] With `curl --http2-prior-knowledge http://localhost:8000` Outputs: <30>Jun 3 17:16:51 haproxy[47829]: http_first_req=0 -Patrick Oh, forgot the version. 1.9.8 -Patrick
Re: cygwin compilation error
вт, 4 июн. 2019 г. в 01:23, Zakharychev, Bob : > Ilya, > > > > Try pulling in gcc-core libgcc1 binutils. I can’t actually see how it’s > compiling without a compiler :), but worth trying. Also, check output from > it had picked gcc from windows :) installing "gcc-core" resolved that > > cpp -v /dev/null -o /dev/null > > > > This should print the search path – we can then verify that /usr/include > and other dirs are in it. > > > > Bob > > > > *From:* Илья Шипицин > *Sent:* Monday, June 3, 2019 4:09 PM > *To:* Zakharychev, Bob > *Cc:* HAProxy > *Subject:* Re: cygwin compilation error > > > > > > I use the following command to build environment: > > > > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10 > > > > > > "poll.h" is located in /usr/include > > > > https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231 >
http_first_req not working with http2
As subject says, it appears that the http_first_req sample is not working with http2. Config: frontend f1 bind :8000 option http-use-htx log-format http_first_req=%[http_first_req] With `curl http://localhost:8000` Outputs: <30>Jun 3 17:16:36 haproxy[47767]: http_first_req=1 Where as, Config: frontend f1 bind :8000 proto h2 option http-use-htx log-format http_first_req=%[http_first_req] With `curl --http2-prior-knowledge http://localhost:8000` Outputs: <30>Jun 3 17:16:51 haproxy[47829]: http_first_req=0 -Patrick
RE: cygwin compilation error
Ilya, Try pulling in gcc-core libgcc1 binutils. I can’t actually see how it’s compiling without a compiler :), but worth trying. Also, check output from cpp -v /dev/null -o /dev/null This should print the search path – we can then verify that /usr/include and other dirs are in it. Bob From: Илья Шипицин Sent: Monday, June 3, 2019 4:09 PM To: Zakharychev, Bob Cc: HAProxy Subject: Re: cygwin compilation error I use the following command to build environment: https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10 "poll.h" is located in /usr/include https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231
Re: cygwin compilation error
btw, Bob, can you run reg-tests on cygwin ? maybe you can prepare travis-ci
config for cygwin ?
вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob :
> Ilya,
>
>
>
> FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with
> GCC toolchain 8.3.0 running just
>
>
>
> make TARGET=cygwin
>
>
>
> and it compiled successfully, but initially didn’t link due to
>
>
>
> src/mux_h2.o: In function `h2s_frt_make_resp_data':
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `trace'
>
> collect2: error: ld returned 1 exit status
>
> make: *** [Makefile:821: haproxy] Error 1
>
>
>
> I think this is due to lack of support for weak function attribute in the
> Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems
> to be mentioning this as well. I added a crude workaround and successfully
> linked the executable with it. Here’s the patch, maybe you folks can
> improve it or just accept it as is. It just uses the TRACE flag and
> conditionally defines the dummy trace() in standard.c if the flag is not
> present (which is essentially the same as having the linker override a weak
> function).
>
>
>
> diff -uw a/src/standard.c b/src/standard.c
>
> --- a/src/standard.c 2019-06-02 06:06:08.0 -0400
>
> +++ b/src/standard.c 2019-06-03 14:23:15.437931700 -0400
>
> @@ -4298,10 +4298,12 @@
>
> }
>
> /* do nothing, just a placeholder for debugging calls, the real one is in
> trace.c */
>
> -__attribute__((weak,format(printf, 1, 2)))
>
> +#ifndef TRACE
>
> +__attribute__((format(printf, 1, 2)))
>
> void trace(char *msg, ...)
>
> {
>
> }
>
> +#endif
>
> /*
>
> * Local variables:
>
>
>
> I also ran into a linker warning when building with Lua support:
>
>
>
> /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> warning: --export-dynamic is not supported for PE+ targets, did you mean
> --export-all-symbols?
>
>
>
> I was able to get rid of it with the following modification to the
> Makefile (what the warning suggested):
>
>
>
> diff -uw a/Makefile b/Makefile
>
> --- a/Makefile 2019-06-02 06:06:08.0 -0400
>
> +++ b/Makefile 2019-06-03 14:48:47.098917100 -0400
>
> @@ -406,6 +406,8 @@
>
> USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
>
># Cygwin adds IPv6 support only in version 1.7 (in beta right now).
>
>TARGET_CFLAGS = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
> -DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
>
> + # --export-dynamic is not the right way to export symbols in Cygwin
>
> + EXPORT_SYMBOL = --export-all-symbols
>
> endif
>
>
>
> # set the default settings according to the target above
>
>
>
> Other than these two rather small issues 2.0-dev5 built successfully on my
> Cygwin (and I then also successfully built it with threading support, PCRE,
> ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t
> run any tests), so something must be missing in your build environment.
> Most system headers should be in /usr/include if cygwin-devel is installed,
> so you might want to start with checking if expected header files are there…
>
>
>
> Hth,
>
>Bob
>
>
>
> *From:* Илья Шипицин
> *Sent:* Monday, June 3, 2019 11:03 AM
> *To:* Gil Bahat
> *Cc:* Willy Tarreau ; HAProxy
> *Subject:* Re: cygwin compilation error
>
>
>
>
>
>
>
> пн, 3 июн. 2019 г. в 20:00, Gil Bahat :
>
> poll.h seems to be present at cygwin-devel:
>
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64
>
>
>
> hope that helps.
>
>
>
>
>
>
>
> cygwin-devel is installed
>
>
>
> https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
>
>
>
>
>
> Regards,
>
>
>
> Gil
>
>
>
> On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин wrote:
>
>
>
>
>
> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>
> Hi Ilya,
>
> On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote:
> > Hello, Gil Bahat!
> >
> > can you help with troubleshooting?
> >
> > I created some basic cygwin CI:
> >
> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
> >
> > it fails with
> >
> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> > #include
> > ^~~~
> > compilation terminated.
> > make: *** [Makefile:830: src/ev_poll.o] Error 1
> >
> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
> >
> > do you know which package does "poll.h" belongs to ?
>
> Interesting, maybe poll() should be disabled on cygwin and we'd only
> keep select ? (just build with "USE_POLL=" for this).
>
>
>
> I'll try that.
>
>
>
> Actually, I think that I need to install some missing cygwin package
>
> (I installed very few of them using "choco install bash make
> openssl-devel cygwin-devel --source cygwin")
>
>
>
>
> Willy
>
>
Re: cygwin compilation error
вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob :
> Ilya,
>
>
>
> FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with
> GCC toolchain 8.3.0 running just
>
>
>
> make TARGET=cygwin
>
>
>
> and it compiled successfully, but initially didn’t link due to
>
>
>
> src/mux_h2.o: In function `h2s_frt_make_resp_data':
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `trace'
>
> collect2: error: ld returned 1 exit status
>
> make: *** [Makefile:821: haproxy] Error 1
>
>
>
> I think this is due to lack of support for weak function attribute in the
> Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems
> to be mentioning this as well. I added a crude workaround and successfully
> linked the executable with it. Here’s the patch, maybe you folks can
> improve it or just accept it as is. It just uses the TRACE flag and
> conditionally defines the dummy trace() in standard.c if the flag is not
> present (which is essentially the same as having the linker override a weak
> function).
>
>
>
> diff -uw a/src/standard.c b/src/standard.c
>
> --- a/src/standard.c 2019-06-02 06:06:08.0 -0400
>
> +++ b/src/standard.c 2019-06-03 14:23:15.437931700 -0400
>
> @@ -4298,10 +4298,12 @@
>
> }
>
> /* do nothing, just a placeholder for debugging calls, the real one is in
> trace.c */
>
> -__attribute__((weak,format(printf, 1, 2)))
>
> +#ifndef TRACE
>
> +__attribute__((format(printf, 1, 2)))
>
> void trace(char *msg, ...)
>
> {
>
> }
>
> +#endif
>
> /*
>
> * Local variables:
>
>
>
> I also ran into a linker warning when building with Lua support:
>
>
>
> /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> warning: --export-dynamic is not supported for PE+ targets, did you mean
> --export-all-symbols?
>
>
>
> I was able to get rid of it with the following modification to the
> Makefile (what the warning suggested):
>
>
>
> diff -uw a/Makefile b/Makefile
>
> --- a/Makefile 2019-06-02 06:06:08.0 -0400
>
> +++ b/Makefile 2019-06-03 14:48:47.098917100 -0400
>
> @@ -406,6 +406,8 @@
>
> USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
>
># Cygwin adds IPv6 support only in version 1.7 (in beta right now).
>
>TARGET_CFLAGS = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
> -DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
>
> + # --export-dynamic is not the right way to export symbols in Cygwin
>
> + EXPORT_SYMBOL = --export-all-symbols
>
> endif
>
>
>
> # set the default settings according to the target above
>
>
>
> Other than these two rather small issues 2.0-dev5 built successfully on my
> Cygwin (and I then also successfully built it with threading support, PCRE,
> ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t
> run any tests), so something must be missing in your build environment.
> Most system headers should be in /usr/include if cygwin-devel is installed,
> so you might want to start with checking if expected header files are there…
>
"something must be missing in your build environment" ... travis-ci is an
ephemeral environment. it is built from scratch every time.
I use the following command to build environment:
https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10
"poll.h" is located in /usr/include
https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231
>
>
> Hth,
>
>Bob
>
>
>
> *From:* Илья Шипицин
> *Sent:* Monday, June 3, 2019 11:03 AM
> *To:* Gil Bahat
> *Cc:* Willy Tarreau ; HAProxy
> *Subject:* Re: cygwin compilation error
>
>
>
>
>
>
>
> пн, 3 июн. 2019 г. в 20:00, Gil Bahat :
>
> poll.h seems to be present at cygwin-devel:
>
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64
>
>
>
> hope that helps.
>
>
>
>
>
>
>
> cygwin-devel is installed
>
>
>
> https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
>
>
>
>
>
> Regards,
>
>
>
> Gil
>
>
>
> On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин wrote:
>
>
>
>
>
> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>
> Hi Ilya,
>
> On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote:
> > Hello, Gil Bahat!
> >
> > can you help with troubleshooting?
> >
> > I created some basic cygwin CI:
> >
> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
> >
> > it fails with
> >
> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> > #include
> > ^~~~
> > compilation terminated.
> > make: *** [Makefile:830: src/ev_poll.o] Error 1
> >
> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
> >
> > do you know which package does "poll.h" belongs to ?
>
> Interesting, maybe poll() should be disabled on cygwin and we'd only
> keep select ? (just build with "USE_POLL=" for this).
>
>
>
> I'll try that.
>
>
>
> Actually, I think that I need to install some missing cygwin package
>
> (I
RE: cygwin compilation error
Ilya,
FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with GCC
toolchain 8.3.0 running just
make TARGET=cygwin
and it compiled successfully, but initially didn’t link due to
src/mux_h2.o: In function `h2s_frt_make_resp_data':
/build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
/build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation truncated
to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:821: haproxy] Error 1
I think this is due to lack of support for weak function attribute in the
Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems to
be mentioning this as well. I added a crude workaround and successfully linked
the executable with it. Here’s the patch, maybe you folks can improve it or
just accept it as is. It just uses the TRACE flag and conditionally defines the
dummy trace() in standard.c if the flag is not present (which is essentially
the same as having the linker override a weak function).
diff -uw a/src/standard.c b/src/standard.c
--- a/src/standard.c 2019-06-02 06:06:08.0 -0400
+++ b/src/standard.c 2019-06-03 14:23:15.437931700 -0400
@@ -4298,10 +4298,12 @@
}
/* do nothing, just a placeholder for debugging calls, the real one is in
trace.c */
-__attribute__((weak,format(printf, 1, 2)))
+#ifndef TRACE
+__attribute__((format(printf, 1, 2)))
void trace(char *msg, ...)
{
}
+#endif
/*
* Local variables:
I also ran into a linker warning when building with Lua support:
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
warning: --export-dynamic is not supported for PE+ targets, did you mean
--export-all-symbols?
I was able to get rid of it with the following modification to the Makefile
(what the warning suggested):
diff -uw a/Makefile b/Makefile
--- a/Makefile 2019-06-02 06:06:08.0 -0400
+++ b/Makefile 2019-06-03 14:48:47.098917100 -0400
@@ -406,6 +406,8 @@
USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
# Cygwin adds IPv6 support only in version 1.7 (in beta right now).
TARGET_CFLAGS = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
-DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
+ # --export-dynamic is not the right way to export symbols in Cygwin
+ EXPORT_SYMBOL = --export-all-symbols
endif
# set the default settings according to the target above
Other than these two rather small issues 2.0-dev5 built successfully on my
Cygwin (and I then also successfully built it with threading support, PCRE,
ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t run
any tests), so something must be missing in your build environment. Most system
headers should be in /usr/include if cygwin-devel is installed, so you might
want to start with checking if expected header files are there…
Hth,
Bob
From: Илья Шипицин
Sent: Monday, June 3, 2019 11:03 AM
To: Gil Bahat
Cc: Willy Tarreau ; HAProxy
Subject: Re: cygwin compilation error
пн, 3 июн. 2019 г. в 20:00, Gil Bahat
mailto:bahat@gmail.com>>:
poll.h seems to be present at cygwin-devel:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64
hope that helps.
cygwin-devel is installed
https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
Regards,
Gil
On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин
mailto:chipits...@gmail.com>> wrote:
пн, 3 июн. 2019 г. в 17:56, Willy Tarreau mailto:w...@1wt.eu>>:
Hi Ilya,
On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote:
> Hello, Gil Bahat!
>
> can you help with troubleshooting?
>
> I created some basic cygwin CI:
>
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>
> it fails with
>
> src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> #include
> ^~~~
> compilation terminated.
> make: *** [Makefile:830: src/ev_poll.o] Error 1
>
> (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>
> do you know which package does "poll.h" belongs to ?
Interesting, maybe poll() should be disabled on cygwin and we'd only
keep select ? (just build with "USE_POLL=" for this).
I'll try that.
Actually, I think that I need to install some missing cygwin package
(I installed very few of them using "choco install bash make openssl-devel
cygwin-devel --source cygwin")
Willy
cygwin build error
Hello, I'm trying yo build haproxy (git master) on cygwin. $ make CC=gcc V=1 TARGET=cygwin FLAGS= ... src/mux_h2.o: In function `h2s_frt_make_resp_data': /home/chipitsine/haproxy/src/mux_h2.c:4405: undefined reference to `trace' /home/chipitsine/haproxy/src/mux_h2.c:4405:(.text+0xce79): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `trace' collect2: error: ld returned 1 exit status make: *** [Makefile:821: haproxy] Error 1
Re: Lua logging to syslog & not stderr
Hi Patrick, On Mon, Jun 03, 2019 at 11:51:12AM -0400, Patrick Hemmer wrote: > Is there a way to have Lua log to syslog only, and not to stderr? When I > call `TXN.log(...)`, the message shows up in syslog AND stderr. > > The Lua documentation implies this is possible as it has this statement > (http://www.arpalert.org/src/haproxy-lua-api/1.9/index.html): > > > The log is sent, according with the HAProxy configuration file, on the > default syslog server if it is configured and on the stderr if it is > allowed. > > So how do I make stderr not allowed? > > In my config, I have the following log related settings in defaults > log 127.0.0.1:514 daemon > option httplog While I don't know, I'm interested in the outcome in case it is a bug. I'd rather make sure we address this before 2.0 as it will be too late after if anyone starts to rely on this "feature". Willy
Re: compression performance drop in v1.9 and v2.0
Hi,
On Mon, Jun 03, 2019 at 06:06:02PM +0900, flamese...@yahoo.co.jp wrote:
> I recently found that compression performance drops down after I update to
> v1.9
>
> I dug a little bit and found that there are many forward calls with a length
> of zero
>
> Breakpoint 1, comp_http_forward_data (s=0x86a620, filter=0x873c70,
> msg=0x86b960, len=0) at src/flt_http_comp.c:386
>
> which did not happen in version 1.8
I could indeed reproduce it and it is a side effect of an optimization
that is not relevant anymore and which even caused some trouble recently.
It also had the bad side effect of feeding the compressor with less data
per call resulting in a lower compression ratio. I've addressed it with
commit a689c3d8d ("MEDIUM: stream: make a full process_stream() loop when
completing I/O on exit") which also happens to fix the tricks for which
some loop detection code was added to process_stream().
For me it significantly improves the situation and in fact I'm seeing
that under certain circumstances I could even make the process crash
in the loop detection before this patch, which doesn't happen anymore.
I'd be interested in hearing about your comparison with 1.8. Also please
note that HTX mode is enabled by default in 2.0-dev while it didn't exist
in 1.8, so you may be interested in testing with and without (disable it
using "no option http-use-htx").
Regards,
Willy
Lua logging to syslog & not stderr
Is there a way to have Lua log to syslog only, and not to stderr? When I call `TXN.log(...)`, the message shows up in syslog AND stderr. The Lua documentation implies this is possible as it has this statement (http://www.arpalert.org/src/haproxy-lua-api/1.9/index.html): > The log is sent, according with the HAProxy configuration file, on the default syslog server if it is configured and on the stderr if it is allowed. So how do I make stderr not allowed? In my config, I have the following log related settings in defaults log 127.0.0.1:514 daemon option httplog -Patrick
Re: cygwin compilation error
пн, 3 июн. 2019 г. в 20:00, Gil Bahat : > poll.h seems to be present at cygwin-devel: > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64 > > hope that helps. > > cygwin-devel is installed https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172 > Regards, > > Gil > > On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин wrote: > >> >> >> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau : >> >>> Hi Ilya, >>> >>> On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote: >>> > Hello, Gil Bahat! >>> > >>> > can you help with troubleshooting? >>> > >>> > I created some basic cygwin CI: >>> > >>> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 >>> > >>> > it fails with >>> > >>> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory >>> > #include >>> > ^~~~ >>> > compilation terminated. >>> > make: *** [Makefile:830: src/ev_poll.o] Error 1 >>> > >>> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) >>> > >>> > do you know which package does "poll.h" belongs to ? >>> >>> Interesting, maybe poll() should be disabled on cygwin and we'd only >>> keep select ? (just build with "USE_POLL=" for this). >>> >> >> I'll try that. >> >> Actually, I think that I need to install some missing cygwin package >> (I installed very few of them using "choco install bash make >> openssl-devel cygwin-devel --source cygwin") >> >> >>> >>> Willy >>> >>
Re: [ANNOUNCE] haproxy-2.0-dev5
пн, 3 июн. 2019 г. в 16:56, Willy Tarreau : > Hi Aleks, > > On Mon, Jun 03, 2019 at 01:42:45PM +0200, Aleksandar Lazic wrote: > > Is this test usefull in docker setup? > > > > ## Starting vtest ## > > Testing with haproxy version: 2.0-dev5 > > #top TEST reg-tests/seamless-reload/abns_socket.vtc FAILED (2.239) > exit=2 > > 1 tests failed, 0 tests skipped, 39 tests passed > > I've seen it fail a few times somewhere else, I think it was in the > Travis tests. I don't know if the test is meaningful or not, nor if it > sure, it was travis-ci :) https://travis-ci.com/haproxy/haproxy/jobs/204882937 > suffers from a race condition (which could explain some random issues). > Or maybe it reports a real bug and we've already been trained to see > false alarms. I hope not. I currently have no opinion on this one and > am not much tempted to invest too much time on it given what remains > to be done. > > Cheers, > Willy > >
Re: cygwin compilation error
poll.h seems to be present at cygwin-devel: https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=x86_64 hope that helps. Regards, Gil On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин wrote: > > > пн, 3 июн. 2019 г. в 17:56, Willy Tarreau : > >> Hi Ilya, >> >> On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote: >> > Hello, Gil Bahat! >> > >> > can you help with troubleshooting? >> > >> > I created some basic cygwin CI: >> > >> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 >> > >> > it fails with >> > >> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory >> > #include >> > ^~~~ >> > compilation terminated. >> > make: *** [Makefile:830: src/ev_poll.o] Error 1 >> > >> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) >> > >> > do you know which package does "poll.h" belongs to ? >> >> Interesting, maybe poll() should be disabled on cygwin and we'd only >> keep select ? (just build with "USE_POLL=" for this). >> > > I'll try that. > > Actually, I think that I need to install some missing cygwin package > (I installed very few of them using "choco install bash make > openssl-devel cygwin-devel --source cygwin") > > >> >> Willy >> >
Re: cygwin compilation error
пн, 3 июн. 2019 г. в 17:56, Willy Tarreau : > Hi Ilya, > > On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote: > > Hello, Gil Bahat! > > > > can you help with troubleshooting? > > > > I created some basic cygwin CI: > > > > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 > > > > it fails with > > > > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory > > #include > > ^~~~ > > compilation terminated. > > make: *** [Makefile:830: src/ev_poll.o] Error 1 > > > > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) > > > > do you know which package does "poll.h" belongs to ? > > Interesting, maybe poll() should be disabled on cygwin and we'd only > keep select ? (just build with "USE_POLL=" for this). > I'll try that. Actually, I think that I need to install some missing cygwin package (I installed very few of them using "choco install bash make openssl-devel cygwin-devel --source cygwin") > > Willy >
Re: cygwin compilation error
Hi Ilya, On Mon, Jun 03, 2019 at 01:57:48PM +0500, ??? wrote: > Hello, Gil Bahat! > > can you help with troubleshooting? > > I created some basic cygwin CI: > > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 > > it fails with > > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory > #include > ^~~~ > compilation terminated. > make: *** [Makefile:830: src/ev_poll.o] Error 1 > > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) > > do you know which package does "poll.h" belongs to ? Interesting, maybe poll() should be disabled on cygwin and we'd only keep select ? (just build with "USE_POLL=" for this). Willy
Re: [ANNOUNCE] haproxy-2.0-dev5
Hi Willy. Mon Jun 03 14:05:07 GMT+02:00 2019 Willy Tarreau : > Hi Aleks, > > On Mon, Jun 03, 2019 at 01:42:45PM +0200, Aleksandar Lazic wrote: > > Is this test usefull in docker setup? > > > > ## Starting vtest ## > > Testing with haproxy version: 2.0-dev5 > > # top TEST reg-tests/seamless-reload/abns_socket.vtc FAILED (2.239) exit=2 > > 1 tests failed, 0 tests skipped, 39 tests passed > > I've seen it fail a few times somewhere else, I think it was in the > Travis tests. I don't know if the test is meaningful or not, nor if it > suffers from a race condition (which could explain some random issues). > Or maybe it reports a real bug and we've already been trained to see > false alarms. I hope not. I currently have no opinion on this one and > am not much tempted to invest too much time on it given what remains > to be done. Full ACK. Let's wait until we have a real problem case > Cheers, > Willy Regardes Aleks
Re: [ANNOUNCE] haproxy-2.0-dev5
Hi Aleks, On Mon, Jun 03, 2019 at 01:42:45PM +0200, Aleksandar Lazic wrote: > Is this test usefull in docker setup? > > ## Starting vtest ## > Testing with haproxy version: 2.0-dev5 > #top TEST reg-tests/seamless-reload/abns_socket.vtc FAILED (2.239) exit=2 > 1 tests failed, 0 tests skipped, 39 tests passed I've seen it fail a few times somewhere else, I think it was in the Travis tests. I don't know if the test is meaningful or not, nor if it suffers from a race condition (which could explain some random issues). Or maybe it reports a real bug and we've already been trained to see false alarms. I hope not. I currently have no opinion on this one and am not much tempted to invest too much time on it given what remains to be done. Cheers, Willy
Re: [ANNOUNCE] haproxy-2.0-dev5
Am 02.06.2019 um 13:00 schrieb Willy Tarreau: > Hi, > > HAProxy 2.0-dev5 was released on 2019/06/02. It added 92 new commits > after version 2.0-dev4. > > This version addresses a small number of no-to-trivial issues met while > working on fixing other bugs and during benchmarks. > > One such issue concerns the excess of wakeup/sleep in the H2 mux since > 1.9, due to the fact that the connection's mux buffer is the same size > as the streams' and that when forwarding large data, each stream is able > to fill the buffer and leave no more room to other ones. There are ways > to address this at the connection management level but this requires to > enforce new internal rules that were not necessarily strict enough yet, > and that would require to carefully recheck the code. This will be for > 2.1. In the mean time, using a list of buffers (buffer ring) for the > connection was way easier and significantly improved the performance, > while taking advance on what was expected for 2.1 without taking much > risk. > > We also noticed that some locks and some atomic operations in the scheduler > were taking a significant amount of time by causing lines to bounce between > all cores. While it's often irritating to see this, I'm reminding myself > that two years ago we were crossing fingers hoping that very basic multi- > threading would be completed in time for 1.8 and that now we've already > reached the point where bouncing CPU cache lines are the factor affecting > the scalability, so I must admit it's quite pleasant to revisit such parts > which were once consdered very fast, because now they're the bottlenecks! > Thus some locks were reviewed again and the ones which were really not > used anymore were released. Others have been identified to be reworked > in 2.1. > > Another indicator that we're getting closer to the release is that we're > mostly facing bugs affecting stable releases as well. For example there > was another bug in the LB code where it's possible to loop forever on a > dead server, which also affects 1.9 and 1.8, the queue dispatching code > was bogus since 1.9, and we discovered that "http-request reject" rules > have never worked well... > > Aside this, some improvements to the HTX code were made to better deal > with 1xx messages. Strictly speaking they were not required for this > version but I predicted that we'd face difficult to fix issues if we were > to postpone them for 2.1, and in practice we found corner cases which are > better addressed since these changes. > > A user-visible change was made (I hate to do this but it has become a > real pain and we'll have more trouble if we don't address it now). It's > the presence of similarly-named servers in the config. I figured that 5 > years later, we continue to warn instead of reject this. Given all the > dynamic stuff people are using, it creates a real havoc to still have to > deal with this, so better reject this now than letting people down this > breach for another 5 years. > > The HTX performance was further increased by allowing zero-copy to be > performed when receiving an H2 message. This will be visible in H2 to > H2 scenarios mostly. In addition, the H2 performance appeared to be > horrible when configured with large buffers, due to a few remaining > bytes available after each message causing some realigns. This was now > fixed. > > The SOCKS4 upstream server code was merged. At the moment while SOCKS4 > happens to work for me, it fails for its author (Alec) and his fix really > bothers me. While merging it we noticed that the current connection layer > is still affected by a few very dirty corner cases that I really don't > like. In short, the handshake code was never used to switch between > reading and writing till now. It's not a big deal since this code is going > to disappear soon, but when working on the replacement part, Olivier found > other deeper issues that I really want to see addressed. Just for this, > I'm expecting at least another -dev next week before a final release as we > can't afford to have dirty hacks in this area in an LTS version or we risk > to pay them the high price. > > I just found while testing this release that "tcp-request inspect-delay" > doesn't work in HTTP+HTX mode (it does not wait). I don't know why yet, > but 1.9 has the same issue. > > Overall most of the performance issues addressed in this version also > affect 1.9 and sometimes even 1.8, so we could expect that a few of them > will be backported later if they are of particular concern. > > Now for the next steps, I'd like to emit another dev version this week > (Wednesday or Thursday depending how things go with the pending issues), > with the hope that we can do 2.0-final the week after, before the 15th. > > Please find the usual URLs below : >Site index : http://www.haproxy.org/ >Discourse: http://discourse.haproxy.org/ >Slack channel: https://slack.haproxy.org/ >Issue tracker:
Re: MEDIUM: Adding upstream socks4 proxy support
Hi Willy, Totally understand. Thank you for the kindness! Regards, Alexander Liu On Mon, Jun 3, 2019 at 5:39 PM Willy Tarreau wrote: > > On Mon, Jun 03, 2019 at 04:50:57PM +0800, Alec Liu wrote: > > Hi Willy, > > > > Good to know it was fixed. > > I will try to do some more testing as well. > > OK. > > > btw: do you mind if I am trying to have the SOCKS4 support backported > > to 1.9 and 1.8? > > We normally don't backport new features into stable versions, as > experience told us that while tempting, over the long term it causes > quite some issues. It may exceptionally happen very early after a > release because something doesn't work as expected or is incomplete, > but we've long past this stage for both 1.8 and 1.9. However if you > are willing to keep your own patch and apply it to your local tree, > and just need some help to review it, I can help here. But I'd still > recommend you to migrate to 2.0 ASAP, this will be less trouble for > you than to maintain your patch set. > > Cheers, > Willy
Re: MEDIUM: Adding upstream socks4 proxy support
On Mon, Jun 03, 2019 at 04:50:57PM +0800, Alec Liu wrote: > Hi Willy, > > Good to know it was fixed. > I will try to do some more testing as well. OK. > btw: do you mind if I am trying to have the SOCKS4 support backported > to 1.9 and 1.8? We normally don't backport new features into stable versions, as experience told us that while tempting, over the long term it causes quite some issues. It may exceptionally happen very early after a release because something doesn't work as expected or is incomplete, but we've long past this stage for both 1.8 and 1.9. However if you are willing to keep your own patch and apply it to your local tree, and just need some help to review it, I can help here. But I'd still recommend you to migrate to 2.0 ASAP, this will be less trouble for you than to maintain your patch set. Cheers, Willy
compression performance drop in v1.9 and v2.0
Hi I recently found that compression performance drops down after I update to v1.9 I dug a little bit and found that there are many forward calls with a length of zero Breakpoint 1, comp_http_forward_data (s=0x86a620, filter=0x873c70, msg=0x86b960, len=0) at src/flt_http_comp.c:386 which did not happen in version 1.8
Re: cygwin compilation error
I forgot to notice - haproxy is very close to 2.0 release (about 2 weeks or so). we wish to be sure it works on cygwin before 2.0 released пн, 3 июн. 2019 г. в 13:57, Илья Шипицин : > Hello, Gil Bahat! > > can you help with troubleshooting? > > I created some basic cygwin CI: > > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 > > it fails with > > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory > #include > ^~~~ > compilation terminated. > make: *** [Makefile:830: src/ev_poll.o] Error 1 > > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) > > do you know which package does "poll.h" belongs to ? > > > пн, 6 мая 2019 г. в 14:57, Gil Bahat : > >> Hi, >> >> is cygwin still supported anymore? the target seems to be present in the >> Makefiles and I'd love to be able to use it. I'm running into what seems to >> be a workable linker error: >> >> $ make TARGET=cygwin >> LD haproxy >> src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of >> `.weak.ist_uc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here >> src/http_act.o:http_act.c:(.rdata+0x440): multiple definition of >> `.weak.ist_lc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here >> src/raw_sock.o:raw_sock.c:(.rdata+0x0): multiple definition of >> `.weak.ist_uc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here >> src/raw_sock.o:raw_sock.c:(.rdata+0x100): multiple definition of >> `.weak.ist_lc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here >> src/proto_uxst.o:proto_uxst.c:(.rdata+0x560): multiple definition of >> `.weak.ist_uc.___chkstk_ms' >> src/mux_h2.o:mux_h2.c:(.rdata+0x800): first defined here >> src/proto_uxst.o:proto_uxst.c:(.rdata+0x660): multiple definition of >> `.weak.ist_lc.___chkstk_ms' >> src/mux_h2.o:mux_h2.c:(.rdata+0x900): first defined here >> src/ev_select.o:ev_select.c:(.rdata+0x20): multiple definition of >> `.weak.ist_uc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here >> src/ev_select.o:ev_select.c:(.rdata+0x120): multiple definition of >> `.weak.ist_lc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here >> src/http_conv.o:http_conv.c:(.rdata+0x60): multiple definition of >> `.weak.ist_uc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here >> src/http_conv.o:http_conv.c:(.rdata+0x160): multiple definition of >> `.weak.ist_lc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here >> src/http_acl.o:http_acl.c:(.rdata+0x280): multiple definition of >> `.weak.ist_uc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here >> src/http_acl.o:http_acl.c:(.rdata+0x380): multiple definition of >> `.weak.ist_lc.' >> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here >> collect2: error: ld returned 1 exit status >> make: *** [Makefile:994: haproxy] Error 1 >> >> it feels like it's something trivial but I'm not versed enough to get a >> hold on it. any help would be appreciated. >> >> Regards, >> >> Gil >> >
Re: cygwin compilation error
Hello, Gil Bahat! can you help with troubleshooting? I created some basic cygwin CI: https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30 it fails with src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory #include ^~~~ compilation terminated. make: *** [Makefile:830: src/ev_poll.o] Error 1 (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 ) do you know which package does "poll.h" belongs to ? пн, 6 мая 2019 г. в 14:57, Gil Bahat : > Hi, > > is cygwin still supported anymore? the target seems to be present in the > Makefiles and I'd love to be able to use it. I'm running into what seems to > be a workable linker error: > > $ make TARGET=cygwin > LD haproxy > src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of > `.weak.ist_uc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here > src/http_act.o:http_act.c:(.rdata+0x440): multiple definition of > `.weak.ist_lc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here > src/raw_sock.o:raw_sock.c:(.rdata+0x0): multiple definition of > `.weak.ist_uc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here > src/raw_sock.o:raw_sock.c:(.rdata+0x100): multiple definition of > `.weak.ist_lc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here > src/proto_uxst.o:proto_uxst.c:(.rdata+0x560): multiple definition of > `.weak.ist_uc.___chkstk_ms' > src/mux_h2.o:mux_h2.c:(.rdata+0x800): first defined here > src/proto_uxst.o:proto_uxst.c:(.rdata+0x660): multiple definition of > `.weak.ist_lc.___chkstk_ms' > src/mux_h2.o:mux_h2.c:(.rdata+0x900): first defined here > src/ev_select.o:ev_select.c:(.rdata+0x20): multiple definition of > `.weak.ist_uc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here > src/ev_select.o:ev_select.c:(.rdata+0x120): multiple definition of > `.weak.ist_lc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here > src/http_conv.o:http_conv.c:(.rdata+0x60): multiple definition of > `.weak.ist_uc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here > src/http_conv.o:http_conv.c:(.rdata+0x160): multiple definition of > `.weak.ist_lc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here > src/http_acl.o:http_acl.c:(.rdata+0x280): multiple definition of > `.weak.ist_uc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here > src/http_acl.o:http_acl.c:(.rdata+0x380): multiple definition of > `.weak.ist_lc.' > src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here > collect2: error: ld returned 1 exit status > make: *** [Makefile:994: haproxy] Error 1 > > it feels like it's something trivial but I'm not versed enough to get a > hold on it. any help would be appreciated. > > Regards, > > Gil >
Re: MEDIUM: Adding upstream socks4 proxy support
Hi Willy, Good to know it was fixed. I will try to do some more testing as well. btw: do you mind if I am trying to have the SOCKS4 support backported to 1.9 and 1.8? Thank you. Regards, Alexander Liu On Mon, Jun 3, 2019 at 2:42 PM Willy Tarreau wrote: > > On Mon, Jun 03, 2019 at 07:19:46AM +0200, Willy Tarreau wrote: > > On Mon, Jun 03, 2019 at 01:40:28AM +0800, Alec Liu wrote: > > > Hi Willy, > > > > > > Your configuration working for me too, but once I have the "mode tcp" > > > changed to "mode http", it was failed. > > > Can you give it a try by changing your testing configuration mode from > > > "mode tcp" to "mode http"? > > > > OK I can now reproduce it this way. And I'm seeing the same problem > > you have regarding epoll_ctl(DEL). I'm anticipating something ugly > > in the lower layers now... > > So as I feared it, it was ugly, but not that much in the end. The problem > stemmed from long ago due to handshake handlers partially dealing for their > events and for others', leaving the connections in a pseudo-random polling > state. And the reason it failed in HTTP mode was because mux-h1 immediately > tries to recv() after a connect(), fails, then subscribes the connection to > polling marking it not ready, then the handshake handlers use this not-ready > mark to stop processing, and did not even enable polling for recv when > leaving, which explains the EPOLL_CTL_DEL you've seen. > > I've fixed the connection issues and also have a working fix for mux-h1 that > I'll ask Christopher confirmation before merging it. > > Now everything works for me, tcp/http, proxy v1/v2/none, with or without > socks4, with or without checks. > > Cheers, > Willy
Re: MEDIUM: Adding upstream socks4 proxy support
On Mon, Jun 03, 2019 at 07:19:46AM +0200, Willy Tarreau wrote: > On Mon, Jun 03, 2019 at 01:40:28AM +0800, Alec Liu wrote: > > Hi Willy, > > > > Your configuration working for me too, but once I have the "mode tcp" > > changed to "mode http", it was failed. > > Can you give it a try by changing your testing configuration mode from > > "mode tcp" to "mode http"? > > OK I can now reproduce it this way. And I'm seeing the same problem > you have regarding epoll_ctl(DEL). I'm anticipating something ugly > in the lower layers now... So as I feared it, it was ugly, but not that much in the end. The problem stemmed from long ago due to handshake handlers partially dealing for their events and for others', leaving the connections in a pseudo-random polling state. And the reason it failed in HTTP mode was because mux-h1 immediately tries to recv() after a connect(), fails, then subscribes the connection to polling marking it not ready, then the handshake handlers use this not-ready mark to stop processing, and did not even enable polling for recv when leaving, which explains the EPOLL_CTL_DEL you've seen. I've fixed the connection issues and also have a working fix for mux-h1 that I'll ask Christopher confirmation before merging it. Now everything works for me, tcp/http, proxy v1/v2/none, with or without socks4, with or without checks. Cheers, Willy
