Re: Trouble starting haproxy on Debian8 (systemd)

❦ 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.

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

❦ 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

Re: Haproxy: support for Haiku

❦ 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

Re: Haproxy: support for Haiku

❦ 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

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

❦ 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

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

❦ 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

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

❦ 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

Re: ip_nonlocal_bind=1 set but sometimes get "cannot bind socket" on reload (-sf)

❦ 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,

Re: [PATCH] CLEANUP: rationalize a bit .gitignore

d we don'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 "res

[PATCH] CLEANUP: don't ignore debian/ directory if present

From: Vincent Bernat <vinc...@bernat.im> 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 45ff1c

[PATCH] CLEANUP: rationalize a bit .gitignore

From: Vincent Bernat <vinc...@bernat.im> 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 th

[PATCH] BUILD: install only relevant and existing documentation

From: Vincent Bernat <vinc...@bernat.im> 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: -

[PATCH] MINOR: lua: fix a spelling error in some error messages

From: Vincent Bernat <vinc...@bernat.im> "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 @@

Re: enabling cpu-map

❦ 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

Re: haproxy doesn't get SIGUSR1

❦ 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

Re: ssl parameters ignored

❦ 25 novembre 2015 20:36 +0100, Lukas Tribus <luky...@hotmail.com> : >>> 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'

Re: HAProxy not processing multibyte variables in URL

❦ 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

Re: Graceful restart of Haproxy with SystemD

❦ 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

Re: haproxy reloads, stale listeners, SIGKILL required

❦ 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 >

Re: haproxy reloads, stale listeners, SIGKILL required

❦ 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

Argument parsing and empty argument list

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 =

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 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

[PATCH] CLEANUP: .gitignore cleanup

From: Vincent Bernat <vinc...@bernat.im> .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. --- .git

Re: [PATCH] CLEANUP: .gitignore cleanup

❦ 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

Re: [PATCH] CLEANUP: .gitignore cleanup

❦ 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

Re: [PATCH] CLEANUP: .gitignore cleanup

❦ 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 >

[PATCH 2/2] BUG/MEDIUM: dns: fix alignment issue when building DNS queries

From: Vincent Bernat <vinc...@bernat.im> 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 r

[PATCH 1/2] BUG/MINOR: dns: fix DNS header definition

From: Vincent Bernat <vinc...@bernat.im> 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 del

Re: [PATCH] CLEANUP: .gitignore cleanup

❦ 8 avril 2016 22:22 +0200, Vincent Bernat <ber...@luffy.cx> : > .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 > fr

[PATCH] CLEANUP: .gitignore cleanup

From: Vincent Bernat <vinc...@bernat.im> .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. --- .git

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 26 mars 2016 18:16 +0100, Vincent Bernat <ber...@luffy.cx> : >> 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

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 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,

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 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

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 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

[PATCH 1/2] CLEANUP: remove unneeded casts

From: Vincent Bernat <vinc...@bernat.im> 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: @@

[PATCH 2/2] CLEANUP: uniformize last argument of malloc/calloc

From: Vincent Bernat <vinc...@bernat.im> 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) + siz

Re: ssl offloading

❦ 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

Re: "Bus error" in dns_build_query on SPARC/Solaris 10

❦ 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/): >> >>

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

❦ 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

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

❦ 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

[PATCH] BUG/MINOR: fix listening IP address storage for frontends (cont)

From: Vincent Bernat <vinc...@bernat.im> 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 48e584

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

❦ 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

[PATCH] BUG/MAJOR: fix listening IP address storage for frontends

From: Vincent Bernat <vinc...@bernat.im> 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 sockadd

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

❦ 19 mai 2016 11:23 +0200, Cyril Bonté <cyril.bo...@free.fr> : >> De: "Vincent Bernat" <ber...@luffy.cx> >> for (; port <= end; port++) { >> l = (struct listener *)calloc(1, sizeof(struct >> listener)); >>

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

❦ 19 mai 2016 11:15 +0200, Vincent Bernat <ber...@luffy.cx> : > 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)

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

❦ 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.

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

❦ 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

Re: Haproxy 1.6.5 listens on all IPv4 addresses

❦ 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

Re: Haproxy 1.6.5 listens on all IPv4 addresses

❦ 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

Re: Haproxy 1.6.5 listens on all IPv4 addresses

❦ 15 mai 2016 09:45 +0200, Vincent Bernat <ber...@luffy.cx> : > 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 &

Re: Haproxy 1.6.5 listens on all IPv4 addresses

❦ 15 mai 2016 09:55 +0200, Vincent Bernat <ber...@luffy.cx> : >> 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 e

[PATCH] BUG/MAJOR: fix listening IP address storage for frontends

From: Vincent Bernat <vinc...@bernat.im> 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 sockadd

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

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) | \

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

You can try this patch to check if it works. >From 74b502bcbef74927b2e006ac399a4d3b3de1d331 Mon Sep 17 00:00:00 2001 From: Vincent Bernat <vinc...@bernat.im> Date: Wed, 18 May 2016 19:38:36 +0200 Subject: [PATCH] MINOR: use a macro for htonll/ntohll Some OS have a definition for hton

Re: haproxy stops responding to maskable signals

❦ 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

Re: [ANNOUNCE] haproxy-1.6.6

❦ 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

Re: [ANNOUNCE] haproxy-1.6.6

❦ 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

Re: [PATCH] Re: make install wants to install haproxy-systemd-wrapper

❦ 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)

Re: Ubuntu 16.04 PPA logs not working

❦ 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

Re: Haproxy 1.6.9 failed to compile regex

❦ 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 > >

Re: [PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully

->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

[PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully

From: Vincent Bernat <vinc...@bernat.im> 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

[PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully

From: Vincent Bernat <vinc...@bernat.im> 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

Re: [ANNOUNCE] haproxy-1.5.19

❦ 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

Re: PIDs are not dying on a reload

❦ 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

Re: PIDs are not dying on a reload

❦ 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

Re: PIDs are not dying on a reload

❦ 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

Re: PIDs are not dying on a reload

❦ 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 |

Re: 1.7.6 redirect regression (commit 73d071ecc84e0f26ebe1b9576fffc1ed0357ef32)

❦ 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

Re: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

❦ 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

Re: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

❦ 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

Re: patch: allow to use any compiler

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

tobre 2017 16:23 +0200 Subject: 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

uger) ――― Original Message ――― From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de> 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

e" ――― Original Message ――― From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de> 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 > > ke

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

;m.ulbr...@tu-braunschweig.de> 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 sig

Re: Haproxy segfault error 4 in libc-2.24

❦ 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".

Re: Haproxy segfault error 4 in libc-2.24

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

Re: Aw: Re: Haproxy segfault error 4 in libc-2.24

❦ 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:

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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). --

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

Re: patch: allow to use any compiler

❦ 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

Re: patch: allow to use any compiler

❦ 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

Re: Client cert verification on some paths

❦ 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,

Re: HTTP/2 stream 1 was not closed cleanly

❦ 4 décembre 2017 12:34 GMT, Gregory Storme  : > haproxy -vv > HA-Proxy version 1.8.0-2~bpo8+1 2017/12/02 If you want to try with 1.8.1, it has just been uploaded. -- Lord, what fools these mortals be! -- William Shakespeare, "A Midsummer-Night's

[PATCH] MINOR: systemd: remove comment about HAPROXY_STATS_SOCKET

From: Vincent Bernat <vinc...@bernat.im> This variable was used by the wrapper which was removed in a6cfa9098e5a. The correct way to do seamless reload is now to enable "expose-fd listeners" on the stat socket. --- contrib/systemd/haproxy.service.in | 2 -- 1 file changed, 2 de

Re: HTTP/2 Termination vs. Firefox Quantum

❦ 21 décembre 2017 09:00 GMT, Maximilian Böhm  : > We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the > backend, jetty 9.3.11.v20160721 with http/1.1 answers requests. > > Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues

[PATCH] MINOR: mworker: exit with 0 on successful exit

Without this patch, when killing the master process, the SIGTERM signal is forwarded to all children. Last children will likely exit with "killed by signal SIGTERM" status which would be converted by an exit with status 143 of the master process. With this patch, the master process takes note it

Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

❦ 22 juin 2018 22:03 +0200, Vincent Bernat  : > if (current_child(exitpid)) { > ha_alert("Current worker %d exited with code > %d\n", exitpid, status); This is a lie, but I don't think it matters much. We could (mentally) t

[PATCH] MINOR: systemd: consider exit status 143 as successful

The master process will exit with the status of the last worker. When the worker is killed with SIGTERM, it is expected to get 143 as an exit status. Therefore, we consider this exit status as normal from a systemd point of view. If it happens when not stopping, the systemd unit is configured to

Re: [ANNOUNCE] haproxy-1.8.13

❦ 30 juillet 2018 20:55 +0200, Willy Tarreau  : > What I don't like with PGP on an exposed machine is that it reduces the > size of your 4096-bit key to the size of your passphrase (which most > often contains much less than the ~700 characters it would need to be > as large), and also increases

Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

❦ 22 juin 2018 22:03 +0200, Vincent Bernat  : > Without this patch, when killing the master process, the SIGTERM > signal is forwarded to all children. Last children will likely exit > with "killed by signal SIGTERM" status which would be converted by an > exit with st

Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

❦ 12 juillet 2018 16:25 +0200, William Lallemand  : > Maybe we could take your first patch for the unit file and backport it in 1.8, > and then make the appropriate changes for 1.9 once the master was > redesigned. Yes, no problem. The first patch should apply without any change on 1.8. I am

Re: Haproxy 1.7.10 constantly restarting

❦ 11 mars 2018 07:19 -0400, Aleksey Gordeev  : > I'm sorry is that question is not suitable. Please give correct channel to > contact. > > It's started about a month ago. I have separate instances of same > version haproxy. One of them restarts every 2 or 3 days. > > I have

<    1   2   3   >