❦ 2 décembre 2017 10:47 GMT, "Aleksandar Lazic" :
> You can use the following line to full fill your request, untested.
>
> bind :443 ssl ca-file "${PATH_TO_CAFILE}" crl-file
> "${PATH_TO_CRLFILE}" verify "${VERIFY_MODE}"
If verify mode is set to optional, on browsers, this will still trigge
❦ 9 octobre 2017 08:49 +0500, Илья Шипицин :
>> > any particular reason for mixing "CC=gcc" with "CC?=gcc" ?
>>
>> I don't see any use of ?=, except for stuff that are expected to be in
>> environment variables (like HOME, DISPLAY, LANG, PATH).
>>
>
> # find . -name Makefile -exec grep -E '^CC'
❦ 8 octobre 2017 15:46 +0500, Илья Шипицин :
>> > while some Makefiles allow to use CC, other just stick to gcc.
>> > I think we should change to
>> >
>> > CC ?= gcc
>>
>> This doesn't change much. You can already override gcc with "make
>> TARGET=... CC=clang". The only thing "?=" is that you
❦ 4 octobre 2017 23:49 +0500, Илья Шипицин :
> while some Makefiles allow to use CC, other just stick to gcc.
> I think we should change to
>
> CC ?= gcc
This doesn't change much. You can already override gcc with "make
TARGET=... CC=clang". The only thing "?=" is that you can do "env
CC=clang
❦ 3 octobre 2017 17:54 +0200, Marcus Ulbrich :
> yes... it crashed after 5mins also without this acl.
I was suspecting this ACL as this is the only one with a
case-insensitive match. But maybe the same codepath is used when
matching header names.
> I should test commenting all acl for testing
❦ 3 octobre 2017 16:34 +0200, Marcus Ulbrich :
> acl badbots hdr_reg(User-Agent) -i -f /etc/haproxy/badbots.lst
> http-request deny if badbots !whitelistips_agents
Try removing this one and check if it still crashes (hoping there is
only one crash).
--
By trying we can easily learn to
❦ 3 octobre 2017 11:29 +0200, Marcus Ulbrich :
> and here is the coredump with libssl and haproxy... I can not get
> clear about this:
Not the same one as previously. But this one is entirely in HAProxy. For
this one, I think an excerpt of your configuration would help. It seems
that one HTTP
❦ 3 octobre 2017 11:15 +0200, lu...@gmx.net :
>> Could you get another one with libssl1.1-dbgsym installed?
>
> Mmmh there is no libssl1.1-dbgsym in stretch, only in sid?
>
> I do think we need those stack traces from libssl.
It should be there. But you need to enable the right repository:
htt
ch
Sent: 2 octobre 2017 19:57 +0200
Subject: Re: Haproxy segfault error 4 in libc-2.24
To: Vincent Bernat
Cc: haproxy@formilux.org
> Okay... I've got a core dump... Thanks a lot!!!
>
> But what this means?
>
>
>
> Program received signal SIGSEGV, Segmentation fault
How many haproxy process do you have? Can you reduce nbprocs to 1 if you set it
to another value? In this case, attach directly to haproxy with gdb -p pid,
type continue to unblock it and wait for the segfault. Then bt full.
On October 2, 2017 6:59:47 PM GMT+02:00, Marcus Ulbrich
wrote:
>no ch
❦ 2 octobre 2017 18:38 +0200, Marcus Ulbrich :
> yes... core of python script is there than... but i can't get one of
> haproxy segfault :-/
Not even in /var/lib/haproxy then?
If it works with the Python script, try set kernel.core_pattern to just
"/tmp/core". Do you get it? If yes, do you ge
❦ 2 octobre 2017 17:06 +0200, Marcus Ulbrich :
> I even get no core dump with the python oneliner either with chroot
> nor without...
So, kernel.core_pattern seems to be problematic (unrelated, but my
python one-liner wasn't totally correct either). Try again with just
"core", the core file sh
-- Shakespeare, "Merchant of Venice"
――― Original Message ―――
From: Marcus Ulbrich
Sent: 2 octobre 2017 16:39 +0200
Subject: Re: Haproxy segfault error 4 in libc-2.24
To: Vincent Bernat
Cc: haproxy@formilux.org
> okay...
>
> $# sysctl kernel.core_pattern
❦ 2 octobre 2017 16:29 +0200, Marcus Ulbrich :
> sorry, but it is commented out... :(
Humm, I don't see how HAProxy would chroot itself without this
directive. Let's try to get the core inside the chroot.
Could you confirm the output of:
sysctl kernel.core_pattern
ls -ld /var/lib/haproxy/t
: Re: Haproxy segfault error 4 in libc-2.24
To: Vincent Bernat
Cc: haproxy@formilux.org
> nope... /var/lib/haproxy/tmp/ directory is left empty after crash...
>
>
> Am 02.10.2017 um 16:09 schrieb Vincent Bernat:
>> ❦ 2 octobre 2017 16:05 +0200, Marcus Ulbrich
>> :
>>
❦ 2 octobre 2017 16:05 +0200, Marcus Ulbrich :
> this is linked to /proc/20313/root -> /var/lib/haproxy
>
> and there is dev/log as empty file..
Then, create /var/lib/haproxy/tmp:
mkdir /var/lib/haproxy/tmp
chmod 1777 /var/lib/haproxy/tmp
You should get the core files in this directory (keep
❦ 2 octobre 2017 15:58 +0200, Marcus Ulbrich :
> Yes there is no core dump...
>
> i've ched it and ist was both unlimited...
And "ls -l /proc/xxx/root" is "/" (where xxx is the PID of one of the
HAProxy processes)?
--
What good is an obscenity trial except to popularize literature?
; Plauger)
――― Original Message ―――
From: Marcus Ulbrich
Sent: 2 octobre 2017 12:49 +0200
Subject: Re: Haproxy segfault error 4 in libc-2.24
To: Vincent Bernat
Cc: haproxy@formilux.org
> Hello Vincent,
>
> thanks for your reply. I have done what you said... but there ist nore
❦ 2 octobre 2017 10:31 +0200, Marcus Ulbrich :
> I am running haproxy 1.7.9-1~bpo9+1 on debian 9.1. And after running a
> while with production data haproxy stops working wiith segmentation
> fault:
>
> haproxy[26291]: segfault at 5562af80e000 ip 7f5985e48149 sp
> 7ffe1d613488 error 4 i
❦ 1 août 2017 12:00 +0200, "Arnaud B." :
> I'm not using peers, it's a feature that I've discovered as you
> mentionned it, seems worth the try.
>
> I'll upgrade to the latest bpo package from Vincent's repository and see
> if it fixes my issue, I'll get back to you if it succeeds or not.
You
❦ 1 août 2017 10:49 +0200, "Arnaud B." :
> thank's Vincent.
>
> Unfortunately, I already am on the latest upstream (not backport though) :
>
> $ apt-get update -qq; apt-cache madison haproxy; dpkg -l|grep -i haproxy
>haproxy | 1.7.8-1~bpo9+1 | http://debian.mirrors.ovh.net/debian
> stretch-
❦ 31 juillet 2017 13:58 +0200, "Arnaud B." :
> I changed my haproxy.cfg to use only the haproxy user instead of
> www-data, but it haven't fixed my undying pid issue, I have the exact
> same stale processes, with a UDP UNCON socket open, no trafic and the
> epoll_wait() on strace.
Unfortunately
❦ 28 juillet 2017 12:09 +0200, "Arnaud B." :
> I'm having an issue on debian 9's stable version of HAProxy :
>
> https://dooby.fr/y/j9qgknb
>
> I have to regularly reload haproxy to fetch new configurations, and it
> now always result on a set of undying pids.
>
> If I strace pid 2677 on this sc
❦ 21 juin 2017 11:48 +0200, William Lallemand :
>> > This bug was fixed in 1.8 (see commit
>> > 9f724edbd8d1cf595d4177c3612607f395b4380e "BUG/MEDIUM: http: Drop the
>> > connection establishment when a redirect is performed"). I attached
>> > the patch. Could you quickly check if it fixes your b
❦ 19 mai 2017 08:28 +0200, Willy Tarreau :
> The problem is that it's what was being attempted during the days of 1.3,
> resulting in still highly bogus versions being deployed in field and
> users being very confident in them because they were recently updated.
> These days, every patch going i
❦ 19 mai 2017 07:04 +0200, Willy Tarreau :
>> I saw many similar issues posted earlier by others, but could not
>> find a thread where this is resolved or fixed in a newer release. We
>> are using Ubuntu 16.04 with distro HAProxy (1.6.3), and see that
>> HAProxy spins at 100% with 1-10 TCP conne
❦ 27 janvier 2017 20:54 -0600, David Morton :
> I have a pretty default Ubuntu 16.04 image on AWS set up with the
> haproxy 1.7 ppa package. I'm not seeing a /var/log/haproxy log file.
>
>
> haproxy config is:
>
> log /dev/loglocal0
> log /dev/loglocal1 notice
> chroot /v
❦ 28 décembre 2016 10:56 +0100, Willy Tarreau :
>> >> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
>> >> after version 1.5.18.
>> >
>> > Would it be possible to queue this patch as well for the next 1.5 (if
>> > any)?
>> >
>> > commit c6ca1aa34dd0e343c9a8754f447730b7563
❦ 28 décembre 2016 09:31 +0100, Vincent Bernat :
>> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
>> after version 1.5.18.
>
> Would it be possible to queue this patch as well for the next 1.5 (if
> any)?
>
> commit c6ca1aa34dd0e343c9a8754f4
❦ 25 décembre 2016 09:54 +0100, Willy Tarreau :
> HAProxy 1.5.19 was released on 2016/12/25. It added 47 new commits
> after version 1.5.18.
Would it be possible to queue this patch as well for the next 1.5 (if
any)?
commit c6ca1aa34dd0e343c9a8754f447730b7563d
Author: Willy Tarreau
Date:
>data_size;
>> if (ts) {
> ^
> will always be true.
Wow, dunno how I missed that!
>> t->current++;
>> stksess_init(t, ts);
>
> Or another way to fix it is to simply move the addition inside the if.
>
> I can modify your patch if you don't have the time, just let me know.
Updated patch sent.
--
Vincent Bernat — vincent.ber...@exoscale.ch
❬❱ https://www.exoscale.ch
From: Vincent Bernat
In case `pool_alloc2()` returns NULL, propagate the condition to the
caller. This could happen when limiting the amount of memory available
for HAProxy with `-m`.
---
src/stick_table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/stick_table.c b
From: Vincent Bernat
In case `pool_alloc2()` returns NULL, propagate the condition to the
caller. This could happen when limiting the amount of memory available
for HAProxy with `-m`.
---
src/stick_table.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/stick_table.c
❦ 7 septembre 2016 16:42 CEST, Veiko Kukk :
>> I tried to upgrade from 1.6.8 to 1.6.9, but found strange errors printed
>> by haproxy 1.6.9. Any ideas, why?
>
> Another strange issue is that 1.6.9 shows:
> Running on OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010
>
> System does have openssl
❦ 29 juillet 2016 20:40 CEST, Shawn Heisey :
> fi; \
> done
> install -d "$(DESTDIR)$(SBINDIR)"
> - install haproxy $(EXTRA) "$(DESTDIR)$(SBINDIR)"
> + install haproxy $(wildcard haproxy-systemd-wrapper) \
> +$(EXTRA) "$(DESTDIR)$(SBINDIR)"
>
You can
❦ 12 juillet 2016 06:44 CEST, Willy Tarreau :
>> If you say you won't have time before
>> end of july, I can do an upload now. If you say you will do it on next
>> week-end, I will happily wait and congratulate myself for not uploading
>> too soon.
>
> Let's say that if on Wednesday evening it's
❦ 30 juin 2016 20:19 CEST, Willy Tarreau :
>> - BUG/MINOR: ssl: fix potential memory leak in ssl_sock_load_dh_params()
>
> For those interested, we found a regression with this patch, some of our
> processes crash with openssl-1.0.2 and dh-param 1024. Setting dh-param 2048
> is enough to work
❦ 8 juin 2016 12:42 CEST, Andrew Kroenert :
> Im having issues with haproxy’s systemd service under puppet control.
>
> Ive implemented the systemd service from haproxy contrib folder, which
> has the ExecStartPre command to check the config.
>
> This works for Starts, but not restarts, and whi
❦ 25 mai 2016 22:15 +0200, Lukas Tribus :
> DNS requests (using the internal resolver) are corrupted since commit
> e2f84977165a ("BUG/MINOR: dns: fix DNS header definition").
>
> Fix it by defining the struct in network byte order, while complying
> with RFC 2535, section 6.1.
So sorry about t
❦ 19 mai 2016 22:09 +0200, Willy Tarreau :
> If you're interested in updating your patch for this I'll happily apply
> it. Otherwise I can do it myself to learn my lesson :-)
I'll let you do it yourself. :)
--
Write clearly - don't be too clever.
- The Elements of Programming Style
❦ 19 mai 2016 09:30 -0400, Jonathan Fisher :
> Where is the git repo for haproxy? having trouble finding the official
> one, all I can find is a mirror on github.
On http://haproxy.org, you have the links in the main table.
--
Don't comment bad code - rewrite it.
- The Elements of
From: Vincent Bernat
Commit 6e6158 was incomplete. There was an additional aggregate copy
that may trigger a similar case in the future.
---
src/cfgparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 48e584cf73e7..9b7646523de9 100644
❦ 19 mai 2016 11:23 +0200, Cyril Bonté :
>> De: "Vincent Bernat"
>> for (; port <= end; port++) {
>> l = (struct listener *)calloc(1, sizeof(struct
>> listener));
>> @@ -291,7 +291,7 @@ int str2listener(char *str,
❦ 19 mai 2016 11:15 +0200, Vincent Bernat :
> This is a backport for 1.5 of
> 3baab74e32ceec987e7ff3db1627b760bbac3027.
Wrong commit number. This should be 6e6158.
--
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)
From: Vincent Bernat
When compiled with GCC 6, the IP address specified for a frontend was
ignored and HAProxy was listening on all addresses instead. This is
caused by an incomplete copy of a "struct sockaddr_storage".
With the GNU Libc, "struct sockaddr_storage"
❦ 19 mai 2016 10:54 +0200, Willy Tarreau :
>> >> When compiled with GCC 6, the IP address specified for a frontend was
>> >> ignored and HAProxy was listening on all addresses instead. This is
>> >> caused by an incomplete copy of a "struct sockaddr_storage".
>> >
>> > Patch applied to both 1.7-
❦ 19 mai 2016 10:46 +0200, Willy Tarreau :
>> When compiled with GCC 6, the IP address specified for a frontend was
>> ignored and HAProxy was listening on all addresses instead. This is
>> caused by an incomplete copy of a "struct sockaddr_storage".
>
> Patch applied to both 1.7-dev and 1.6. I
❦ 18 mai 2016 22:56 +0200, Pavlos Parissis :
>> Also, where is the bugtracker for haproxy? I can file a report if you
>> want to save time.
>
> As far as I know there isn't any bugtracker. Posting problems in this
> ML is enough to kick the investigation. So far this model works quite
> well
Ye
You can try this patch to check if it works.
>From 74b502bcbef74927b2e006ac399a4d3b3de1d331 Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Wed, 18 May 2016 19:38:36 +0200
Subject: [PATCH] MINOR: use a macro for htonll/ntohll
Some OS have a definition for htonll/ntohll using a regu
Hey!
Since there is some discrepancy in the definition of ntohll among
platforms, I define this macro to shadow any existing definition:
#ifndef ntohll
# define ntohll(x) \
(((u_int64_t)(ntohl((int)(((x) << 32) >> 32))) << 32) | \
(
From: Vincent Bernat
When compiled with GCC 6, the IP address specified for a frontend was
ignored and HAProxy was listening on all addresses instead. This is
caused by an incomplete copy of a "struct sockaddr_storage".
With the GNU Libc, "struct sockaddr_storage"
❦ 15 mai 2016 09:55 +0200, Vincent Bernat :
>> I suppose that some new features of gcc started to rely on the
>> strict-aliasing rule without taking -fno-strict-aliasing into
>> consideration. I didn't find anything in the bugzilla, but it's easy to
>> miss som
❦ 15 mai 2016 09:45 +0200, Vincent Bernat :
> I suppose that some new features of gcc started to rely on the
> strict-aliasing rule without taking -fno-strict-aliasing into
> consideration. I didn't find anything in the bugzilla, but it's easy to
> miss something as th
❦ 15 mai 2016 09:19 +0200, Willy Tarreau :
>> I think this is an aliasing problem. You cannot have two incompatible
>> variables pointing at the same memory spot. It seems that now
>> sockaddr_storage and sockaddr_in are not compatible anymore.
>
> Here it's not an aliasing problem in my opinion
❦ 14 mai 2016 15:20 +0200, Cyril Bonté :
>>> What is the most important is to report this to the gcc maintainers so that
>>> they can fix the bug. The fix will naturally flow into the distros.
>>>
>>
>> I understand this and of course I could try to fill a bug on their side but
>> the gcc stuff
❦ 1 mai 2016 22:31 +0300, Alexander Piavlo :
> Then trying to gracefully reload haproxy often it fails to reload
> saying that it cannot bind to sockets. From what i see the old process
> does not close the listening sockets, and thus replacement process
> fails. Trying to send old haproxy proc
❦ 12 avril 2016 12:08 +0200, Willy Tarreau :
>> > With your change it's fine on my side so I guess it's version agnostic. We
>> > can merge this one if you want.
>>
>> Yes, I am totally fine with it. :)
>
> OK merged now. I gues you'd like it backported as well to ease your
> package maintainer
❦ 12 avril 2016 11:43 +0200, Willy Tarreau :
>> I don't understand, because for me, those rules at the top were masked
>> by, for example, "!/contrib". Maybe it's a matter of git version? I am
>> using 2.8.0.rc3.
>
> Possible indeed. I have 1.7.12.1 here, and 2.8 at home (which I use less
> ofte
❦ 12 avril 2016 10:38 +0200, Willy Tarreau :
> BTW, armv5 is very handy to test alignment. By default it does crap
> (silent read of the wrong word) but you can configure it to fault or
> to emulate the alignment. I've found lots of such issues with just
> a Seagate Dockstar.
Funny fact, I did
From: Vincent Bernat
.gitignore is an odd beast. All the stuff at the beginning is useless
since in the bottom part starts with /.* and /*. Therefore, the top part
is useless. Moreover, the bottom part makes unignore *.o and
friends. Add it back at the bottom.
---
.gitignore | 62
❦ 12 avril 2016 10:47 +0200, Willy Tarreau :
> I guess most of them come from the following rules that are not covered
> anymore :
>
> -*~
> -*.bak
> -*.orig
> -*.rej
> -*.service
> -dlmalloc.c
>
> and contrib/* and -tests/test_hashes.
I don't understand, because for me, those rules
❦ 8 avril 2016 22:17 +0200, Vincent Bernat :
> On some architectures, unaligned access is not authorized. On most
> architectures, it is just slower. Therefore, we have to use memcpy()
> when an unaligned access is needed, specifically when writing the qinfo.
>
> Also remov
❦ 8 avril 2016 22:22 +0200, Vincent Bernat :
> .gitignore is an odd beast. All the stuff at the beginning is useless
> since in the bottom part starts with /.* and /*. Therefore, the top part
> is useless. Moreover, the bottom part makes unignore *.o and
> friends. Add it back a
From: Vincent Bernat
.gitignore is an odd beast. All the stuff at the beginning is useless
since in the bottom part starts with /.* and /*. Therefore, the top part
is useless. Moreover, the bottom part makes unignore *.o and
friends. Add it back at the bottom.
---
.gitignore | 49
From: Vincent Bernat
On some architectures, unaligned access is not authorized. On most
architectures, it is just slower. Therefore, we have to use memcpy()
when an unaligned access is needed, specifically when writing the qinfo.
Also remove the unaligned access when reading answer count when
From: Vincent Bernat
Conforming to RFC 2535, section 6.1. This is not an important bug as
those fields don't seem to be set to something else than 0 and to be
checked on answers.
---
include/types/dns.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/in
❦ 29 mars 2016 16:52 +0200, Willy Tarreau :
>> l = calloc(1, sizeof(struct listener));
>
> I definitely agree. This code is quite old (2005) and we don't do that
> much cleanup passes unfortunately. Oh and yes by the way, in case people
> have doubts about this, I wrote it and used to proceed li
From: Vincent Bernat
Instead of repeating the type of the LHS argument (sizeof(struct ...))
in calls to malloc/calloc, we directly use the pointer
name (sizeof(*...)). The following Coccinelle patch was used:
@@
type T;
T *x;
@@
x = malloc(
- sizeof(T)
+ sizeof(*x)
)
@@
type T;
T *x
From: Vincent Bernat
In C89, "void *" is automatically promoted to any pointer type. Casting
the result of malloc/calloc to the type of the LHS variable is therefore
unneeded.
Most of this patch was built using this Coccinelle patch:
@@
type T;
@@
- (T *)
(\(lua_touserdata\|mall
❦ 1 avril 2016 11:11 +0200, Conrad Hoffmann :
> I can't really back this up with reliable numbers, but a company I once
> worked for experimented with such hardware. The outcome was, and I would
> still always recommend this today, to rather throw more regular hardware at
> the problem. Modern
❦ 29 mars 2016 17:27 +0200, Willy Tarreau :
>>
>> @@
>> type T;
>> @@
>>
>> - (T\( \|\)*)
>> (\(lua_touserdata\|malloc\|calloc\)(...))
>>
>> So, I can rebase the patch as long as it's needed.
>
> Perfect. Then I'll try to flush the large queue ASAP so that we can
> apply such changes. If yo
❦ 29 mars 2016 16:52 +0200, Willy Tarreau :
>l = calloc(1, sizeof(*l));
[...]
>> I can propose a (large) patch to remove all those casts (using a
>> semantic patch to not miss anything). Here is a preview (for master,
>> only src/):
>>
>> https://gist.github.com/dc61d8b035545dc24efd
>>
>>
❦ 26 mars 2016 18:16 +0100, Vincent Bernat :
>> Hi, Vincent! Thanks for your answer!
>> I made some tests today. Yes, it crashes only if hostname contains an
>> odd number of symbols!
>
> So, it should be easy to fix. Baptiste, do you want a patch or are my
> explan
❦ 26 mars 2016 23:40 +0600, Александр Лебедев
:
> Hi, Vincent! Thanks for your answer!
> I made some tests today. Yes, it crashes only if hostname contains an
> odd number of symbols!
So, it should be easy to fix. Baptiste, do you want a patch or are my
explanations enough?
--
Make sure speci
❦ 26 mars 2016 08:33 +0100, Baptiste :
>> When I use resolvers check in 1.6.3 haproxy, it is crashed with "Bus error".
>> pstack with core file shows me:
>>
>> 000a6d1c dns_build_query (11f921, 1c, 16a650, 21, 11f8f0, 1238f0) + a8
>> 000a6d58 dns_send_query (16a698, 10be18, 0, 13ac90, 0, 8f1b) +
Hey!
The documentation of req.hdr() says that "name" is optional. However, no
match can bound without specifying the name. In `smp_fetch_hdr()`, we
have:
#v+
if (args) {
if (args[0].type != ARGT_STR)
return 0;
name_str = args[0].data
❦ 3 février 2016 14:37 GMT, David Birdsong :
> right, thanks, but again, I'm familiar w/ haproxy and graceful
> reloads. I've used lsof -Pnp , and I find that sometimes an old
> haproxy process is still listening for new connections. This is the
> problem I'm trying to ask if anyone else is als
❦ 3 février 2016 00:11 GMT, David Birdsong :
> I'm not using consul but am using haproxy in a docker container
> and reloading when backend hosts change registrations. I haven't
> seen this issue. I run using haproxy-systemd-wrapper and HUP that
> process to reload.
>
> does tha
❦ 14 janvier 2016 20:37 +0100, Willy Tarreau :
>> Good news, there is nothing wrong in haproxy, the "-L" option is
>> correctly applied to he loaded configuration.
>
> Great!
>
>> But the init script first checks the configuration in
>> check_haproxy_config(), which doesn't take into account E
❦ 16 décembre 2015 16:32 -0800, Marc Fournier :
> Damn … Apache does, but, Wordpress doesn’t … unless we’ve missed
> something, but you have to make a choice with Wordpress … either its a
> https:// site, or its a http:// site … they hard code the protocol /
> url right into the database …
>Fro
❦ 15 décembre 2015 22:34 -0800, Marc Fournier :
> [ALERT] 349/062436 (12994) : parsing [/etc/haproxy/haproxy.cfg:34] : 'bind
> :443' : 'alpn' : library does not support TLS ALPN extension
> [ALERT] 349/062436 (12994) : Error(s) found in configuration file :
> /etc/haproxy/haproxy.cfg
> [ALERT]
❦ 3 décembre 2015 08:59 +0100, SL :
> I'm trying to use the cpu-map directive on haproxy 1.6 (Debian 8), but
> am getting the error:
>
> 'cpu-map' is not enabled, please check build options for
> USE_CPU_AFFINITY
>
> I understand from this that I need to recompile with some different
> options,
❦ 2 décembre 2015 09:30 +0100, Lukas Tribus :
> Also see Lukas Lösche's reports and efforts:
> https://github.com/haproxy/haproxy/issues/48
Totally unrelated with the current issue, but on the GitHub page, this
is said that issues are ignored but some of them are actually
active. It's possible
❦ 27 novembre 2015 13:00 +0900, "Yu Watanabe" :
> I would like to ask a question to people in this forum.
>
> I appreciate if someone can help me out.
>
> Currently, I am using haproxy 1.5.14 on CentOS 6.6 64bit)
>
> My HAProxy is having problem when multibyte language is included in
> the GET r
❦ 25 novembre 2015 20:36 +0100, Lukas Tribus :
>>> I don't know. I got pre made packages from "http://haproxy.debian.net
>>> jessie-backports-1.6 main" maintained by Vincent Bernat if I'm correct.
>>
>> I think there's something wrong w
❦ 16 novembre 2015 16:51 +0100, SL :
> Process: 3751 ExecStartPre=/usr/local/sbin/haproxy -f ${CONFIG} -c -q
> (code=exited, status=2)
Execute this command manually. This is the one checking if the
configuration is correct.
--
Every cloud engenders not a storm.
-- William Shake
❦ 1 novembre 2015 21:21 +0100, Willy Tarreau :
>> > If nobody objects, I'd rather do that so that you don't have to add
>> > a specific if/elif/endif just for this. What do you think ?
>>
>> On the other hand, it is not really systemd-specific (and could be made
>> not Linux-specific if it was
❦ 1 novembre 2015 20:20 +0100, Willy Tarreau :
> This case is not specific to your operating system, in fact only a
> minority of platforms need the systemd-wrapper. I personally build
> with "make ... EXTRA=" to avoid building it and installing it. I
> think we took the wrong approach by enabl
❦ 30 octobre 2015 15:14 -0400, Chris Riley :
> SigQ: 3/63840
> SigPnd:
> SigBlk: fffe7bfa7a26
> SigIgn: 1000
> SigCgt: 000180300205
SigIgn is correct (SIGPIPE) is ignored. However, SigBlk seems
incorrect. HAProxy only blocks signals when dequeuing them. Howe
❦ 30 octobre 2015 14:50 -0400, Chris Riley :
> Good idea. I just tried and it appears to be in an epoll_wait loop.
> This is after sending the PID SIGTTOU and SIGUSR1. SIGTERM also has no
> effect, the process stays in this epoll_wait loop.
>
> strace -p11537
> Process 11537 attached - interrupt
❦ 30 octobre 2015 14:36 -0400, Chris Riley :
> When the processes stack up, the old ones don't respond to anything
> other than 'kill -9'.
You could try to strace them to check where they currently are.
--
If more of us valued food and cheer and song above hoarded gold, it would
be a merrier w
❦ 30 octobre 2015 10:50 -0400, Chris Riley :
> I'm going to compile the 3.10 kernel from CentOS 7 for CentOS 6 and
> see if the behavior persists and report back.
With a 3.10, you are unlikely to get the same behaviour as two processes
are allowed to listen to the same IP/port. So, if it's a po
❦ 30 octobre 2015 00:34 -0400, Chris Riley :
> The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS
> 6.4.
With this version of the kernel, the previous instance of HAProxy has to
release the port before the new one can bind. It seems that in your
case, this doesn't happen. Nothin
❦ 29 octobre 2015 15:16 -0400, Chris Riley :
> Reloading haproxy: [ALERT] 301/141300 (25939) : Starting proxy
> haproxy-stats: cannot bind socket [192.168.10.27:80]
> [ALERT] 301/141300 (25939) : Starting proxy haproxy-fe1: cannot bind
> socket [192.168.200.100:80]
> [ALERT] 301/141300 (25939) :
From: Vincent Bernat
This makes packaging with git tools easier as it is not possible to
cancel anything in debian/.gitignore since the whole directory is
ignored.
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 45ff1c37236e..0292bcc1b4ce 100644
on't know all
> of them, I think that instead we should enumerate what we want to keep here.
> Having "debian" listed here seems perfectly fine to me. And if other distros
> need other entries, let's have them contribute a patch. It will also be a
> nice way to "
From: Vincent Bernat
Commit 80c2f2f024a104bb7e135cbed5ee923e4a6d8dba added a bunch of stuff
in .gitignore making it difficult for downstreams to work with
HAProxy. When a directory is ignored, it is impossible to cancel this
with a .gitignore inside the directory.
In the case of Debian, I need
From: Vincent Bernat
doc/haproxy-{en,fr}.txt have been removed recently but they were still
referenced in the Makefile. Many other documents have also been
added. Instead of hard-coding a list of documents to install, install
all those in doc/ with some exceptions:
- coding-style.txt is more
From: Vincent Bernat
"unknown" was spelled "unkown".
---
src/hlua.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/hlua.c b/src/hlua.c
index ae3fe8938f6b..c797d4011129 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -1261,7 +1261,7 @@ __LJMP sta
❦ 23 juillet 2015 08:41 +0200, Willy Tarreau :
>> > I suppose that either -ldl could be added to OPTIONS_LDFLAGS append,
>> > like this is done for -lm. Or USE_DL section could be moved towards the
>> > end. I think the first solution is better since libdl seems to be a
>> > dependency of lua.
>
101 - 200 of 312 matches
Mail list logo
