Re: [PATCH 1.5 0/4] Manpage fixes
Hi Apollon, On Sun, Sep 29, 2013 at 11:03:11PM +0300, Apollon Oikonomopoulos wrote: Hi, The following set of patches updates the manpage, adding missing options, removing obsolete options and fixing external references. Regards, Apollon Apollon Oikonomopoulos (4): DOC: add missing options to the manpage DOC: add manpage references to all system calls DOC: update manpage reference to haproxy-en.txt DOC: remove -s and -l options from the manpage All the series applied, thank you. Just for your information, I manually fixed a harmless space that was added in the first and the last patch and which made git am complain. Thanks! Willy
Re: Static haproxy/openssl build error
Hi Vincent, On Sun, Sep 29, 2013 at 10:27:30PM +0200, Vincent Bernat wrote: ??? 29 septembre 2013 18:30 CEST, Willy Tarreau w...@1wt.eu : So maybe we should in fact stop setting PCREDIR to $(pcre-config --prefix), which will result in PCRE_INC/PCRE_LIB remaining silent unless PCREDIR is forced. I suspect the following patch should fix it : diff --git a/Makefile b/Makefile index 0529e89..89f9f39 100644 --- a/Makefile +++ b/Makefile @@ -544,7 +544,6 @@ ifneq ($(USE_PCRE)$(USE_STATIC_PCRE)$(USE_PCRE_JIT),) # Forcing PCREDIR to an empty string will let the compiler use the default # locations. -PCREDIR:= $(shell pcre-config --prefix 2/dev/null || echo /usr/local) ifneq ($(PCREDIR),) PCRE_INC := $(PCREDIR)/include PCRE_LIB := $(PCREDIR)/lib I would use `pcre-config --libs` and `pcre-config --cflags` instead. The user can still override this on make command line. PCRE_CFLAGS := $(shell pcre-config --cflags) PCRE_LIBS := $(shell pcre-config --libs) But these would still cause the issue we're currently facing because they'll add -L/usr/lib or whatever is in the system path, so that does not fix the issue. Really I'd rather get rid of pcre-config completely. Anyway, in cross-compile environments, you can't use it and you have to force the value otherwise you're screwed, and in local builds, you simply don't need to specify them. As for the ordering of -L, I would expect the user to specify `make LDFLAGS=-L/tmp/openssl/static` and you rename the internal `LDFLAGS` to something else (instead of introducing another variable, LDFLAGS is the variable that a user can expect to override). $(LDFLAGS) will be used early (as currently done), so the specified directory will be first in the search path. That's interesting. In fact, the worst problem we have is that (except for ADDINC/ADDLIB), the variables the user can specify already hold a value and are overridden. That's how we added more and more variables, so that you can specify extra build information without losing existing ones. I've just checked, and all my build scripts already specify LDFLAGS, but just for passing -g/-s/-static (basically what we can expect in LDFLAGS), but none of them expects LDFLAGS to also override ARCH_FLAGS. So I think it could already improve things if instead of having : LDFLAGS = $(ARCH_FLAGS) -g ... $(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS) we had : LDFLAGS = -g ... $(LD) $(ARCH_FLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) or even ideally : ARCH_LDFLAGS = $(ARCH_FLAGS) LDFLAGS = -g ... $(LD) $(ARCH_LDFLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) I think we wouldn't break existing build scripts by such a small change and would make it easier for packagers to force some paths without the risk of overriding the arch-specific flags. Willy
Re: Static haproxy/openssl build error
Hi Lukas,
On Sun, Sep 29, 2013 at 10:49:41PM +0200, Lukas Tribus wrote:
Another thing regarding SSL_INC/SSL_LIB: when linking against static openssl,
libdl is necessary. Previously I did this by appending ADDLIB with -ldl. It
seems like doing the same in SSL_LIB doesn't work (for me), because -ldl must
come after -lssl -lcrypto.
Now, should we advise users and document to use something like this:
SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl
Like previsouly suggested by Apollon, we could introduce a flag for
statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?).
If we do that, we could also include -ldl automatically when using that USE
flag.
Thoughts?
I'm a bit hesitant here and am not completely fond of what we did for
PCRE_STATIC. The problem is that we force -Wl,-Bstatic then -Wl,-Bdynamic,
and that it breaks full static builds. There's no option in the linker
like -Wl,-Bdefault to say let's come back to the default model, so
we have to force dynamic by hand at the end of inclusion of the lib
and complicate the things. For PCRE, the solution consists in using USE_PCRE
instead of USE_STATIC_PCRE when doing a full static build. But if for SSL
we automatically add -ldl, you quickly see the issue happen.
Or maybe we could have a variable BUILD_MODEL = {static,dynamic} that
we use to set the fallback mode and take the correct decisions when adding
libraries.
Anyway, I tend to prefer to let people pass an option to fix their build
issues than having a few other ones patch the makefile to get rid of
something that was added for laziness and breaks their build. Let's not
try to reproduce the autotools mess with a makefile :-)
Regards,
Willy
Re: Static haproxy/openssl build error
❦ 30 septembre 2013 11:30 CEST, Willy Tarreau w...@1wt.eu : I would use `pcre-config --libs` and `pcre-config --cflags` instead. The user can still override this on make command line. PCRE_CFLAGS := $(shell pcre-config --cflags) PCRE_LIBS := $(shell pcre-config --libs) But these would still cause the issue we're currently facing because they'll add -L/usr/lib or whatever is in the system path, so that does not fix the issue. Really I'd rather get rid of pcre-config completely. Anyway, in cross-compile environments, you can't use it and you have to force the value otherwise you're screwed, and in local builds, you simply don't need to specify them. For me, pcre-config --libs does not use `-L`. Dunno why this is the case for Apollon. For cross-compile, triplet-enabled pcre-config should be available (this is tested by autoconf) but on cross-compile toolchain that I see nowadays, the PATH is made such that you find pcre-config for crosscompilation before the one for the system. I don't know if a user is expected to rely on this. As for the ordering of -L, I would expect the user to specify `make LDFLAGS=-L/tmp/openssl/static` and you rename the internal `LDFLAGS` to something else (instead of introducing another variable, LDFLAGS is the variable that a user can expect to override). $(LDFLAGS) will be used early (as currently done), so the specified directory will be first in the search path. That's interesting. In fact, the worst problem we have is that (except for ADDINC/ADDLIB), the variables the user can specify already hold a value and are overridden. That's how we added more and more variables, so that you can specify extra build information without losing existing ones. I've just checked, and all my build scripts already specify LDFLAGS, but just for passing -g/-s/-static (basically what we can expect in LDFLAGS), but none of them expects LDFLAGS to also override ARCH_FLAGS. So I think it could already improve things if instead of having : LDFLAGS = $(ARCH_FLAGS) -g ... $(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS) we had : LDFLAGS = -g ... $(LD) $(ARCH_FLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) or even ideally : ARCH_LDFLAGS = $(ARCH_FLAGS) LDFLAGS = -g ... $(LD) $(ARCH_LDFLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) I think we wouldn't break existing build scripts by such a small change and would make it easier for packagers to force some paths without the risk of overriding the arch-specific flags. Yes, this seems fine. -- Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan Plauger)
Re: Static haproxy/openssl build error
Hi Vincent,
On 12:19 Mon 30 Sep , Vincent Bernat wrote:
For me, pcre-config --libs does not use `-L`. Dunno why this is the
case for Apollon.
My version of pcre-config (8.30, also tested with 8.31) includes:
libS=
if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
libS=-L${prefix}/lib/x86_64-linux-gnu
fi
So, it seems it tries to be smart, but is not multiarch aware (I'll open
a bug against it). This would obviously work correctly in squeeze,
except that the version in squeeze lacks even this simple test :-)
pkg-config on the other hand works better:
$ pkg-config --libs libpcre
-lpcre
Apollon
Re: Static haproxy/openssl build error
On 13:49 Mon 30 Sep , Apollon Oikonomopoulos wrote:
Hi Vincent,
On 12:19 Mon 30 Sep , Vincent Bernat wrote:
For me, pcre-config --libs does not use `-L`. Dunno why this is the
case for Apollon.
My version of pcre-config (8.30, also tested with 8.31) includes:
libS=
if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
libS=-L${prefix}/lib/x86_64-linux-gnu
fi
Update:
Debian's 8.31 (testing/unstable) actually does not emit -L using
pcre-config. I just looked at the source, but did a wrong ./configure.
The actual script shipping with the package tests /usr/lib against
/usr/lib. I assume that's the version you're running Vincent, right?
Apollon
about stats socket per process
I would like to ask you about any perspective in implementation statistics socket at each process in nbproc. Do you have any plans to work on it? Thanks. -- The more you know, the less you need. Rgrds, Pavel Morozov
Re: Static haproxy/openssl build error
❦ 30 septembre 2013 13:01 CEST, Apollon Oikonomopoulos apoi...@gmail.com :
My version of pcre-config (8.30, also tested with 8.31) includes:
libS=
if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
libS=-L${prefix}/lib/x86_64-linux-gnu
fi
Update:
Debian's 8.31 (testing/unstable) actually does not emit -L using
pcre-config. I just looked at the source, but did a wrong ./configure.
The actual script shipping with the package tests /usr/lib against
/usr/lib. I assume that's the version you're running Vincent, right?
Yes.
--
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan Plauger)
Re: Client timeout on http put shows as a server timeout with error 504
*From: *Patrick Hemmer hapr...@stormcloud9.net *Sent: * 2013-09-18 10:26:36 E *To: *haproxy@formilux.org *Subject: *Re: Client timeout on http put shows as a server timeout with error 504 *From: *Willy Tarreau w...@1wt.eu *Sent: * 2013-09-18 01:46:50 E *To: *Patrick Hemmer hapr...@stormcloud9.net *CC: *haproxy@formilux.org haproxy@formilux.org *Subject: *Re: Client timeout on http put shows as a server timeout with error 504 Hi Patrick, On Tue, Sep 17, 2013 at 06:29:13PM -0400, Patrick Hemmer wrote: We have this case with haproxy 1.5-dev19 where when a client is uploading data via a HTTP PUT request, the client will fail to send all it's data and haproxy will timeout the connection. The problem is that haproxy is reporting this an error 504 and connection flags of sH--, meaning it timed out waiting for the server. Now I've analyzed the http headers, and the PUT request has a content-length header, so would it be possible to have haproxy report these as a client side timeout instead of a server side timeout (when the amount of data after headers is less than the amount indicated in the content-length header)? And with a 4XX status code as well. We have monitoring in place which looks for server errors, and I'd love for it not to pick up client problems. I remember having checked for this in the past. I agree that ideally we should have a cH--. It's a bit trickier, because in practice it is permitted for the server to respond before the end. In fact we'd need another state before the Headers state, which is the client's body, so that we can report exactly what we were waiting for. I could check if it's easier to implement now. A first step could be to disable the server-side timeout as long as we're waiting for the client. That might do the trick. Probably that you could already check for this using a slightly larger server timeout than the client's (eg: 21s for the server, 20s for the client). If that works, it would confirm that we could do this by just disabling the server timeout in this situation. Seems like it's not going to be that simple. We currently have the server timeout set at 170s, and the client timeout at 60s (and the connection closes with 504 sH-- after 170s). Though this does seem like it'd be the right approach; if the client hasn't finished sending all it's data, the client timeout should kick in. -Patrick I'm also seeing a lot of connections being closed by the client and showing up as 503 (connection flags are CC--), and in my opinion the client closing the connection shouldn't be a 500 level error. In this specific case, nginx uses code 499. Perhaps haproxy should adopt this code as well. For this and the timeout issue, if this isn't something that will be fixed any time soon, I'm willing to try and dig into it myself. However I don't know the haproxy source, so it will likely take me quite some time. -Patrick
RE: Static haproxy/openssl build error
Hi Willy,
Like previsouly suggested by Apollon, we could introduce a flag for
statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?).
If we do that, we could also include -ldl automatically when using that USE
flag.
Thoughts?
I'm a bit hesitant here and am not completely fond of what we did for
PCRE_STATIC. The problem is that we force -Wl,-Bstatic then -Wl,-Bdynamic,
and that it breaks full static builds. There's no option in the linker
like -Wl,-Bdefault to say let's come back to the default model, so
we have to force dynamic by hand at the end of inclusion of the lib
and complicate the things.
I see; I was not aware of this problem.
Or maybe we could have a variable BUILD_MODEL = {static,dynamic} that
we use to set the fallback mode and take the correct decisions when adding
libraries.
You mean maintaining the USE_STATIC_LIBXY approach and use the BUILD_MODEL
variable to fix this problem? Could be a possibility, but its gets more
complex again; perhaps we should rethink the whole USE_STATIC_LIBXY approach
instead? Not sure.
Anyway, I tend to prefer to let people pass an option to fix their build
issues than having a few other ones patch the makefile to get rid of
something that was added for laziness and breaks their build.
Agreed.
Sending the README patch about SSL_INC/SSL_LIB now.
Regards,
Lukas
[PATCH] DOC: ssl: update build instructions to use new SSL_* variables
Since commit 9a05945bd (BUILD: add SSL_INC/SSL_LIB variables to force the path to openssl) we have SSL_INC and SSL_LIB to point to the libssl installation. This commits updates the build instructions in README accordingly. --- README |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README b/README index 1742680..b90e54e 100644 --- a/README +++ b/README @@ -97,9 +97,9 @@ keyword and install it to a local directory, so your system is not affected : $ ./config --prefix=$STATICLIBSSL no-shared $ make make install_sw -When building haproxy, pass that path via ADDINC and ADDLIB to make and include -libdl (-ldl). -$ make TARGET=linux2628 USE_OPENSSL=1 ADDINC=-I$STATICLIBSSL/include ADDLIB=-L$STATICLIBSSL/lib -ldl +When building haproxy, pass that path via SSL_INC and SSL_LIB to make and +include additional libs with ADDLIB if needed (in this case for example libdl): +$ make TARGET=linux26 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl It is also possible to include native support for ZLIB to benefit from HTTP compression. For this, pass USE_ZLIB=1 on the make command line and ensure -- 1.7.9.5
3 formules pour apprendre l'anglais
3 formules pour parler anglais : http://www.englishspeakit.fr
Re: [PATCH] DOC: ssl: update build instructions to use new SSL_* variables
On Tue, Oct 01, 2013 at 12:28:03AM +0200, Lukas Tribus wrote: Since commit 9a05945bd (BUILD: add SSL_INC/SSL_LIB variables to force the path to openssl) we have SSL_INC and SSL_LIB to point to the libssl installation. This commits updates the build instructions in README accordingly. Applied, thanks Lukas! Willy
