Re: [PATCH] BUILD: Silence gcc warning about unused return value

2019-06-12 Thread Vincent Bernat
❦ 12 juin 2019 20:47 +02, Tim Duesterhus : > - write(2, trash.area, trash.data); > + shut_your_big_mouth_gcc(write(2, trash.area, trash.data)); An alternative not discussed in 89efaed6b67b (which introduced this function) is to use "(void)!": (void)!write(2, trash.area, trash.data);

Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-12 Thread Vincent Bernat
❦ 8 mai 2019 13:44 +00, Veiko Kukk : >> It was slightly modified to cleanly apply, because HAProxy's default >> unit file does not include rsyslog.service as an 'After' dependency. >> Also the subject line was modified to include the proper subsystem >> and severity. > > I think, instead of

Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-08 Thread Vincent Bernat
❦ 8 mai 2019 16:23 +02, Tim Düsterhus : >> I think, instead of After=rsyslog.service, it should be >> After=syslog.service, then any logger daemon could be used that has >> Alias=syslog.service. >> >> https://www.freedesktop.org/wiki/Software/systemd/syslog/ >> > > The HAProxy provided unit

Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-06 Thread Vincent Bernat
❦ 6 mai 2019 13:46 +02, William Lallemand : >> /etc/default is a debianism. Other distros use different directories, >> such as RedHat which uses /etc/sysconfig >> >> -Patrick > > Hi Patrick, > > I don't think that's a problem, most distribution use their own unit file > anyway, people should

Re: [ANNOUNCE] haproxy-1.8.20

2019-05-05 Thread Vincent Bernat
❦ 5 mai 2019 09:51 +02, Vincent Bernat : >> So I'd suggest to insist on having the up to date version (even 1.8.21 if >> we have a reason to have this one released by then). In the worst case, >> if this is rejected for whatever reason, it's better to leave a wel

Re: [ANNOUNCE] haproxy-1.8.20

2019-05-05 Thread Vincent Bernat
❦ 5 mai 2019 09:14 +02, Willy Tarreau : > So I'd suggest to insist on having the up to date version (even 1.8.21 if > we have a reason to have this one released by then). In the worst case, > if this is rejected for whatever reason, it's better to leave a well known > version there and continue

Re: [ANNOUNCE] haproxy-1.8.20

2019-05-04 Thread Vincent Bernat
❦ 29 avril 2019 11:04 +02, Christopher Faulet : > HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits > after version 1.8.19. Hey! Debian Buster will soon be released (nobody knows exactly when, but we are in full freeze since 2 months). It currently contains HAProxy 1.8.19. I

Re: haproxy segfault

2019-02-12 Thread Vincent Bernat
❦ 12 février 2019 21:44 +01, Mildis : > I'm struggling with Stretch/systemd to generate the coredump on crash. > Even running haproxy by hand with ulimit -c unlimited does not > generate a coredump. Also install haproxy-dbgsym. You need to comment the chroot directive in your HAProxy

Re: DNS resolution issue with Docker swarm and HAProxy 1.8.15/1.9.0

2018-12-20 Thread Vincent Bernat
❦ 20 décembre 2018 17:14 +01, Willy Tarreau : >> this is indeed a regression in haproxy. thanks for reporting it. >> attached patch should fix it. >> CC'ing Remi as the original author, and Baptiste, as DNS maintainer. > > Good catch, the patch looks obviously good, I've just merged it. >

Re: [ANNOUNCE] haproxy-1.8.13

2018-07-30 Thread Vincent Bernat
❦ 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

2018-07-12 Thread Vincent Bernat
❦ 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: [PATCH] MINOR: mworker: exit with 0 on successful exit

2018-07-12 Thread Vincent Bernat
❦ 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

2018-06-22 Thread Vincent Bernat
❦ 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: mworker: exit with 0 on successful exit

2018-06-22 Thread 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 status 143 of the master process. With this patch, the master process takes note it

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

2018-06-22 Thread Vincent Bernat
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: Haproxy 1.7.10 constantly restarting

2018-03-11 Thread Vincent Bernat
❦ 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

Re: Syslog with systemd

2018-03-02 Thread Vincent Bernat
❦ 2 mars 2018 19:24 +1100, Igor Cicimov  : >> I suppose the permissions of /var/log are incorrect. It should be owned >> by syslog? > > ​The permissions look ok: > ​ > ​# ls -ld /var/log/ > drwxrwxr-x 16 root syslog 4096 Mar 2 00:00 /var/log/ > # id -a syslog >

Re: Syslog with systemd

2018-03-01 Thread Vincent Bernat
❦ 2 mars 2018 09:49 +1100, Igor Cicimov  : > $ ls -l /var/log/haproxy.log > -rw-r- 1 syslog adm 48939 Mar 1 20:17 /var/log/haproxy.log > > ​and I'm sure this file was automatically created ​(by rsyslog I guess?). > I'm sure this has always been the case

Re: Syslog with systemd

2018-02-28 Thread Vincent Bernat
❦ 1 mars 2018 09:53 +1100, Igor Cicimov  : >> > ​Same, no logging:​ >> [...] >> >> Could you strace rsyslogd and check if it is receiving the messages? > > > ​Sure: > > # pidof rsyslogd > 4145 > # strace -p 4145 > strace: Process 4145 attached > select(1, NULL,

Re: Syslog with systemd

2018-02-28 Thread Vincent Bernat
❦ 28 février 2018 22:14 +1100, Igor Cicimov  : > ​Same, no logging:​ [...] Could you strace rsyslogd and check if it is receiving the messages? -- This is the first age that's paid much attention to the future, which is a little ironic since we may not have one.

Re: Syslog with systemd

2018-02-28 Thread Vincent Bernat
❦ 28 février 2018 21:00 +1100, Igor Cicimov  : > ​# ls -l /var/lib/haproxy/dev/log > srw-rw-rw- 1 root root 0 Feb 28 16:06 /var/lib/haproxy/dev/log > > # lsof -n -p $(pidof haproxy) | grep dev/log > # In fact, this seems expected because HAProxy is only using

Re: Syslog with systemd

2018-02-27 Thread Vincent Bernat
❦ 28 février 2018 17:51 +1100, Igor Cicimov  : >> > ​Actually spoke too soon, still have an issue. One of the servers started >> > logging there but then stopped and on the other the file is still empty.​ >> >> Is the issue fixed just by restarting HAProxy or does

Re: Syslog with systemd

2018-02-27 Thread Vincent Bernat
❦ 28 février 2018 15:50 +1100, Igor Cicimov  : > ​Actually spoke too soon, still have an issue. One of the servers started > logging there but then stopped and on the other the file is still empty.​ Is the issue fixed just by restarting HAProxy or does it persist

Re: [PATCH 0/2] Add SystemD's sandboxing options

2018-02-27 Thread Vincent Bernat
❦ 27 février 2018 16:00 +0100, Willy Tarreau  : >> I'm running this exact settings on my Debian Stretch machine using haproxy >> 1.8.x, without issues so far. >> >> The first patch could cause issues for users that store their configuration >> in /home or /root, but I consider this

Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-21 Thread Vincent Bernat
❦ 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: systemd: remove comment about HAPROXY_STATS_SOCKET

2017-12-08 Thread Vincent Bernat
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 stream 1 was not closed cleanly

2017-12-04 Thread Vincent Bernat
❦ 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

Re: Client cert verification on some paths

2017-12-02 Thread Vincent Bernat
❦ 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: patch: allow to use any compiler

2017-10-08 Thread Vincent Bernat
❦ 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

2017-10-08 Thread Vincent Bernat
❦ 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: patch: allow to use any compiler

2017-10-04 Thread Vincent Bernat
❦ 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: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
❦ 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: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
❦ 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

2017-10-03 Thread Vincent Bernat
❦ 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: Aw: Re: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
;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

2017-10-02 Thread Vincent Bernat
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: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
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

2017-10-02 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
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

2017-10-02 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
❦ 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

2017-10-02 Thread Vincent Bernat
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

2017-10-02 Thread Vincent Bernat
❦ 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: PIDs are not dying on a reload

2017-08-01 Thread Vincent Bernat
❦ 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

2017-08-01 Thread Vincent Bernat
❦ 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: PIDs are not dying on a reload

2017-08-01 Thread Vincent Bernat
❦ 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

2017-07-28 Thread Vincent Bernat
❦ 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: 1.7.6 redirect regression (commit 73d071ecc84e0f26ebe1b9576fffc1ed0357ef32)

2017-06-22 Thread Vincent Bernat
❦ 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

2017-05-19 Thread Vincent Bernat
❦ 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: HAProxy 1.6.3: 100% cpu utilization for >17 days with 1 connection

2017-05-18 Thread Vincent Bernat
❦ 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: Ubuntu 16.04 PPA logs not working

2017-01-27 Thread Vincent Bernat
❦ 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: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Vincent Bernat
❦ 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: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Vincent Bernat
❦ 28 décembre 2016 09:31 +0100, Vincent Bernat <ber...@luffy.cx> : >> 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 c6ca1aa

Re: [ANNOUNCE] haproxy-1.5.19

2016-12-28 Thread Vincent Bernat
❦ 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

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

2016-11-17 Thread Vincent Bernat
->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

2016-11-17 Thread Vincent Bernat
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

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

2016-11-17 Thread Vincent Bernat
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

Re: Haproxy 1.6.9 failed to compile regex

2016-09-07 Thread Vincent Bernat
❦ 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] Re: make install wants to install haproxy-systemd-wrapper

2016-07-29 Thread Vincent Bernat
❦ 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: [ANNOUNCE] haproxy-1.6.6

2016-07-11 Thread Vincent Bernat
❦ 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: [ANNOUNCE] haproxy-1.6.6

2016-07-11 Thread Vincent Bernat
❦ 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: Graceful restart of Haproxy with SystemD

2016-06-08 Thread Vincent Bernat
❦ 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: [PATCH] BUG/MEDIUM: dns: unbreak DNS resolver after header fix

2016-05-25 Thread Vincent Bernat
❦ 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

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

2016-05-19 Thread Vincent Bernat
❦ 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: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

2016-05-19 Thread Vincent Bernat
❦ 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.

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

2016-05-19 Thread Vincent Bernat
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

2016-05-19 Thread Vincent Bernat
❦ 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

2016-05-19 Thread Vincent Bernat
❦ 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)

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

2016-05-19 Thread Vincent Bernat
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

2016-05-19 Thread Vincent Bernat
❦ 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

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

2016-05-19 Thread Vincent Bernat
❦ 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

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

2016-05-18 Thread Vincent Bernat
❦ 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: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

2016-05-18 Thread Vincent Bernat
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: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

2016-05-18 Thread Vincent Bernat
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) | \

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

2016-05-18 Thread Vincent Bernat
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: Haproxy 1.6.5 listens on all IPv4 addresses

2016-05-18 Thread Vincent Bernat
❦ 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

Re: Haproxy 1.6.5 listens on all IPv4 addresses

2016-05-15 Thread Vincent Bernat
❦ 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

2016-05-15 Thread Vincent Bernat
❦ 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

2016-05-14 Thread Vincent Bernat
❦ 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 stops responding to maskable signals

2016-05-01 Thread Vincent Bernat
❦ 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: [PATCH] CLEANUP: .gitignore cleanup

2016-04-12 Thread Vincent Bernat
❦ 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 >

Re: [PATCH] CLEANUP: .gitignore cleanup

2016-04-12 Thread Vincent Bernat
❦ 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

[PATCH] CLEANUP: .gitignore cleanup

2016-04-12 Thread Vincent Bernat
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

2016-04-12 Thread Vincent Bernat
❦ 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

2016-04-08 Thread Vincent Bernat
❦ 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

2016-04-08 Thread Vincent Bernat
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

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

2016-04-08 Thread Vincent Bernat
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

2016-04-08 Thread Vincent Bernat
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: "Bus error" in dns_build_query on SPARC/Solaris 10

2016-04-03 Thread Vincent Bernat
❦ 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 2/2] CLEANUP: uniformize last argument of malloc/calloc

2016-04-03 Thread Vincent Bernat
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

[PATCH 1/2] CLEANUP: remove unneeded casts

2016-04-03 Thread Vincent Bernat
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: @@

Re: ssl offloading

2016-04-01 Thread Vincent Bernat
❦ 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

2016-03-29 Thread Vincent Bernat
❦ 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

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

2016-03-29 Thread Vincent Bernat
❦ 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: "Bus error" in dns_build_query on SPARC/Solaris 10

2016-03-27 Thread Vincent Bernat
❦ 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

2016-03-26 Thread Vincent Bernat
❦ 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

2016-03-26 Thread Vincent Bernat
❦ 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,

  1   2   3   >