Re: [ANNOUNCE] haproxy-2.4.0
❦ 17 mai 2021 17:48 +02, Artur: > When can we expect prebuilt packages for Debian on haproxy.debian.net > ? Hello, Sometimes this week. -- The secret source of humor is not joy but sorrow; there is no humor in Heaven. -- Mark Twain
Re: [ANNOUNCE] haproxy-2.4.0
❦ 17 mai 2021 17:48 +02, Artur: > When can we expect prebuilt packages for Debian on haproxy.debian.net > ? They have been published. Buster, Bionic and Focal are available. -- He jests at scars who never felt a wound. -- Shakespeare, "Romeo and Juliet, II. 2"
Re: Official ubuntu 20 repository
❦ 6 June 2021 11:54 +01, Ismail Azerty: > Is there any official ubuntu 20 repository to install the latest > version of haproxy ? This is semi-official: https://haproxy.debian.net/#?distribution=Ubuntu&release=focal -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.3.12
❦ 8 July 2021 17:47 +02, Willy Tarreau: > I'm seeing that at least Vincent was fast enough to package 2.3.11 for > debian 10, I hope nobody deployed it yet. I'm really sorry for the mess. > For those who are wondering, 2.4 was not affected. The new packages are available! -- Let the data structure the program. - The Elements of Programming Style (Kernighan & Plauger)
Re: Test, please ignore
❦ 23 July 2021 12:55 +02, Willy Tarreau: > The list looks uncommonly quiet after having touched some > anti-spam rules, just testing. It's the holidays Willy! :) -- Don't over-comment. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] HTTP/2 vulnerabilities from 2.0 to 2.5-dev
❦ 17 August 2021 17:13 +02, Willy Tarreau: > HAProxy is affected by 4 vulnerabilities in its HTTP/2 implementation in > recent versions (starting with 2.0). Three of them are considered as having > a moderate impact as they only affect the interpretation of the authority > (Host header field) in H2->H2 communications in versions 2.2 and above. > One only affects a risk of misinterpretation from lenient HTTP/1 backend > servers, and affects version 2.0 and above, though at the time of writing > we're not aware of any such vulnerable server among the mainstream ones > that are commonly found behind HAProxy (Apache, NGINX, Varnish, etc). For users of haproxy.debian.net or Launchpad PPA, the vulnerabilities are fixed by patching the previous versions. Launchpad PPA builders are still running but it should be available in the next hour. I will upload the new versions later this week. Check the changelog (in /usr/share/doc/haproxy/changelog.Debian.gz) if you want to know if you are running a fixed version. The list of fixed versions are: haproxy_2.4.2-2~bpo10+1 haproxy_2.4.2-2~bpo11+1 haproxy_2.4.2-2ppa1~bionic haproxy_2.4.2-2ppa1~focal haproxy_2.2.9-2+deb11u1 (should be available from debian-security soon) haproxy_2.3.12-2~bpo10+1 haproxy_2.3.12-2ppa1~bionic haproxy_2.3.12-2ppa1~focal haproxy_2.2.15-3~bpo9+1 haproxy_2.2.15-3~bpo10+1 haproxy_2.2.15-3ppa1~bionic haproxy_2.2.15-3ppa1~focal haproxy_2.0.23-3~bpo9+1 haproxy_2.0.23-3~bpo10+1 haproxy_2.0.23-3ppa1~xenial haproxy_2.0.23-3ppa1~bionic haproxy_2.0.23-3ppa1~focal -- Make input easy to proofread. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev
❦ 7 September 2021 17:27 +02, Willy Tarreau: > I'd like to thank the usual distro maintainers for having accepted to > produce yet another version of their packages in a short time. Hopefully > now we can all get back to development! For Debian/Ubuntu, the fixed versions are: 2.4.3-2 2.4.3-2~bpo10+1 2.4.3-2~bpo11+1 2.4.3-2ppa2~bionic 2.4.3-2ppa1~focal 2.3.13-2 2.3.13-2~bpo10+1 2.3.13-2ppa1~bionic 2.3.13-2ppa1~focal 2.2.16-3 2.2.16-3~bpo9+1 2.2.16-3~bpo10+1 2.2.16-3ppa1~bionic 2.2.16-3ppa1~focal 2.2.9-2+deb11u2 (to be released pretty soon) 2.2.9-2+deb11u2~bpo10+1 (not released yet) 2.2.9-1ubuntu0.2 (not 100% sure as it is not released yet) 2.0.24-1 2.0.24-1~bpo9+1 2.0.24-1~bpo10+1 2.0.24-1ppa1~xenial 2.0.24-1ppa1~bionic 2.0.24-1ppa1~focal 2.0.13-2ubuntu0.3 (not 100% sure as it is not released yet) -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev
❦ 8 September 2021 09:02 +02, Artur: > Hello, > > Thank you. > > Could you please explain the version numbering differences between official > haproxy release and the linux distributions > packages ? > > For example : 2.4.4 (official) -> 2.4.3-2~bpo10+1 (Debian 10 > backports) 2.4.3-2~bpo10+1 means this is based on upstream version 2.4.3, second revision for Debian (-2), backport to Debian 10 (~bpo10), first iteration of the backport (+1). The changelog (in ~doc/haproxy/changelog.Debian.gz) gives a hint of the deviation compared to official upstream version: haproxy (2.4.3-2~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. -- Vincent Bernat Sat, 04 Sep 2021 15:19:43 +0200 haproxy (2.4.3-2) experimental; urgency=high * d/patches: fix missing header name length check in HTX (CVE-2021-40346). -- Vincent Bernat Sat, 04 Sep 2021 11:56:31 +0200 haproxy (2.4.3-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. -- Vincent Bernat Sat, 21 Aug 2021 16:47:45 +0200 haproxy (2.4.3-1) experimental; urgency=medium * New upstream release. * d/patches: remove patches applied upstream. * d/patches: h2: match absolute-path not path-absolute for :path. -- Vincent Bernat Sat, 21 Aug 2021 16:32:25 +0200 Debian packages are not based on 2.4.4 because they were prepared in advance to be ready when the vulnerability is announced. Packages based on 2.4.4 will get available later this week. -- Instrument your programs. Measure before making "efficiency" changes. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.4.5
❦ 3 October 2021 08:53 +02, Christopher Faulet: > I will push a fix. As a workaround, you can temporarily disable the HTTP > compression filter. Will you release 2.4.6 or should we push packages for 2.4.5 with the patch? For Debian/Ubuntu, I didn't push packages for 2.4.5 yet. -- Don't sacrifice clarity for small gains in "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
[PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS
Some distributions (Debian) adds `-ffile-prefix-map=/current/pwd=` to CFLAGS in an attempt to make the package more reproducible when source code is using `__FILE__`. Unfortunately, this makes HAProxy build not reproducible since CFLAGS is recorded to be displayed in `haproxy --version`. To solve this, we filter out these arguments as they are not really important to report to the user. This could be backported to 2.4. Older versions do not display CFLAGS. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 50a21b3105cd..6597f0bf855f 100644 --- a/Makefile +++ b/Makefile @@ -968,7 +968,7 @@ src/haproxy.o: src/haproxy.c $(DEP) -DBUILD_ARCH='"$(strip $(ARCH))"' \ -DBUILD_CPU='"$(strip $(CPU))"' \ -DBUILD_CC='"$(strip $(CC))"' \ - -DBUILD_CFLAGS='"$(strip $(VERBOSE_CFLAGS))"' \ + -DBUILD_CFLAGS='"$(filter-out -ffile-prefix-map=% -fmacro-prefix-map=% -fdebug-prefix-map=%,$(strip $(VERBOSE_CFLAGS)))"' \ -DBUILD_OPTIONS='"$(strip $(BUILD_OPTIONS))"' \ -DBUILD_DEBUG='"$(strip $(DEBUG))"' \ -DBUILD_FEATURES='"$(strip $(BUILD_FEATURES))"' \ -- 2.33.0
Re: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS
❦ 19 October 2021 09:22 +02, Vincent Bernat: > This could be backported to 2.4. Older versions do not display CFLAGS. Note that if you find this too ugly, I have no problem to maintain this as an OOT patch. -- Avoid unnecessary branches. - The Elements of Programming Style (Kernighan & Plauger)
Re: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS
❦ 22 October 2021 21:08 +02, Willy Tarreau: >> ? 19 October 2021 09:22 +02, Vincent Bernat: >> >> > This could be backported to 2.4. Older versions do not display CFLAGS. >> >> Note that if you find this too ugly, I have no problem to maintain this >> as an OOT patch. > > I don't find it ugly. I think it's not the most elegant part of the > makefile, but a makefile (and ours in particular) is generally not a > collection of elegant stuff. > > I'm just thinking, we have a SILENT_DEFINE macro that should already > address this. Could you please try to pass your -f... there ? If it > works it would just be a matter of improving the SILENT_DEFINE > description to indicate that it works as well for compiler options > that we don't want to see on the output. I don't use it directly, it's pushed by Debian build system with some other flags. I could puts all of them (-g -O2 -ffile-prefix-map=/home/bernat/code/exoscale/haproxy=. -fstack-protector-strong -Wformat -Werror=format-security) in SILENT_DEFINE, but if at somepoint, some of them are more invasive, it would may not be a good idea to hide them out of your view. Maybe just sit on the patch and see if another distro see a need for it. I'll keep it as a Debian patch for now and I'll complain in a few years if I am tired of it. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.2.18
❦ 5 November 2021 17:05 -06, Jim Freeman: > Might this (or something 2.4-ish) be heading towards bullseye-backports ? > https://packages.debian.org/search?keywords=haproxy > https://packages.debian.org/bullseye-backports/ 2.4 will be in bullseye-backports. -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.5.2
❦ 16 February 2022 16:27 +01, Willy Tarreau: > Maybe that would even be a nice improvement for distros to provide these > by default starting with 2.6 or maybe even 2.5. Why not enabling them directly on your side then? Are there some numbers on the performance impact of these options? I am a bit uncomfortable providing packages that perform slower than an upstream build. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.5.2
❦ 16 February 2022 22:15 +01, Willy Tarreau: > That's exactly the sense behind the word "maybe" above, to open the > discussion :-) Those with large buffers can definitely see a > difference. I've seen configs with WAF analysis using 1MB buffers, > and there the extra CPU usage will be noticeable, maybe 5-10%. My > impression is that the vast majority of users rely on distro packages > and are not sensitive to performance (typically sites like haproxy.org > where enabling everything has no measurable impact, when I'm lucky I > see 1% CPU). Those who deal with high levels of traffic tend to be > forced to follow stable updates more often, they'll typically build > from the Git tree, and are also more at ease with debugging options. > That was my reasoning, it may be wrong, and I perfectly understand > your point which is equally valid. And I'm not even asking for a > change, just saying "maybe it would be even better if". For Debian, being a binary distribution, we cannot be flexible with the users. In the past, we were often told we were less performant than a source distribution because we didn't enable this or this optimization. Also, 1% CPU increase could also translate to increased latency. As a comparison, we did not have memory cgroups in our kernels until the overhead was reduced quite significantly when not using them. On our side, we believe everyone is using Debian packages. ;-) -- Be careful of reading health books, you might die of a misprint. -- Mark Twain
Re: [PATCH 1/1: BUILD/MINOR: TCP_KEEPIDLE macos equivalence
❦ 8 May 2022 10:57 +02, Willy Tarreau: > After edition (still minimal and possibly inaccurate but the best I > could do): > > On Linux the interval before starting to send TCP keep-alive packets > is defined by TCP_KEEPIDLE. MacOS has an equivalent with TCP_KEEPIDLE, > which also uses seconds as a unit, so it's possible to simply remap the > definition of TCP_KEEPIDLE to TCP_KEEPALIVE there and get it to seamlessly > work. The other settings (interval and count) are not present, > though. First instance of TCP_KEEPIDLE should be TCP_KEEPALIVE. ;-) -- Treat end of file conditions in a uniform manner. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.6.0
❦ 31 May 2022 17:56 +02, Willy Tarreau: > HAProxy 2.6.0 was released on 2022/05/31. It added 57 new commits > after version 2.6-dev12, essentially small bug fixes, QUIC counters > and doc updates. It's available on haproxy.debian.net. No QUIC support as neither Debian nor Ubuntu has the appropriate library. -- The better part of valor is discretion. -- William Shakespeare, "Henry IV"
Re: [ANNOUNCE] haproxy-2.6.0
On 6/14/22 14:22, Artur wrote: No plan to prepare 2.6 packages for Debian 10 ? If you can, I'm interested. Thank you. No particular reason, just nobody asked for it. It will land shortly.
Re: Config will not start on 2.6.1 on Ubuntu 22.04
On 7/6/22 00:37, Henning Svane wrote: I get under load of haproxy the following problems for all frontends What do you mean by "under load"? Here are two of the errors for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for IPv4 number and port and for frontend GLOBAL: cannot bind UNIX socket (Permission denied) [/run/haproxy/admin.sock] global maxconn 8000 log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon I have compared folder permission /run/haproxy on Ubuntu 20.04.4 with Ubuntu 22.04 and the permission looks like this for both. [/run/haproxy/admin.sock have these permission drwxrwsr-x 2 haproxy haproxy 40 Jul 5 20:01 haproxy I have tried your configuration on a freshly installed Ubuntu 22.04 and didn't run into any issue. Are you using apparmor? `journalctl -k | grep haproxy` may give a hint if you have a profile for it (not shipped by the package nor Ubuntu as far as I can see).
Re: SV: Config will not start on 2.6.1 on Ubuntu 22.04
comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.752:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=790 comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.752:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=790 comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.756:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/snapd/snap-confine" pid=791 comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.756:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=791 comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.760:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=792 comm="apparmor_parser" Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 audit(1657047250.764:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/chronyd" pid=793 comm="apparmor_parser" Regards Henning *Fra:*Vincent Bernat *Sendt:* 6. juli 2022 19:06 *Til:* haproxy@formilux.org *Cc:* Henning Svane *Emne:* Re: Config will not start on 2.6.1 on Ubuntu 22.04 On 7/6/22 00:37, Henning Svane wrote: I get under load of haproxy the following problems for all frontends What do you mean by "under load"? Here are two of the errors for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for IPv4 number and port and for frontend GLOBAL: cannot bind UNIX socket (Permission denied) [/run/haproxy/admin.sock] global maxconn 8000 log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon I have compared folder permission /run/haproxy on Ubuntu 20.04.4 with Ubuntu 22.04 and the permission looks like this for both. [/run/haproxy/admin.sock have these permission drwxrwsr-x 2 haproxy haproxy 40 Jul 5 20:01 haproxy I have tried your configuration on a freshly installed Ubuntu 22.04 and didn't run into any issue. Are you using apparmor? `journalctl -k | grep haproxy` may give a hint if you have a profile for it (not shipped by the package nor Ubuntu as far as I can see).
Re: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04
The error when not running as root is expected. However, the fact it does not work on boot, then works after is odd. Can you share a minimal configuration file which exhibits this issue? On 7/8/22 23:43, Henning Svane wrote: Hi Vincent And found out if I started the service manual with sudo it also worked sudo service haproxy start odin@haproxyxmail01:~$ systemctl status haproxy.service ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2022-07-08 23:39:11 CEST; 5s ago Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz Main PID: 1945 (haproxy) Tasks: 17 (limit: 4578) Memory: 22.0M CPU: 945ms CGroup: /system.slice/haproxy.service ├─1945 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock └─1947 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock sudo ls -l /run/haproxy.pid -rw-r--r-- 1 root root 5 Jul 8 23:39 /run/haproxy.pid Haproxy.pid will only be created it haproxy/haproxy.service has been started with sudo else it is missing Regards Henning -Oprindelig meddelelse- Fra: Henning Svane Sendt: 8. juli 2022 23:32 Til: Vincent Bernat Cc: haproxy@formilux.org Emne: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04 Hi Vincent I have now build 2 new Ubuntu 22.04 servers It looks like when haproxy service is started under boot it do not have permission to bind to interfaces. If I from console start haproxy manual with sudo it works, but not without sudo, then it behaves like when the haproxy.services is started under boot. So my question how to fix this? So the service is started with permission to bind to interfaces. I can see haproxy.service has these permissions -rw-r--r-- 1 root root 1506 Jun 22 20:49 /lib/systemd/system/haproxy.service Start of service under boot: systemctl status haproxy.service × haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2022-07-08 16:13:25 CEST; 1min 56s ago Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz Process: 1069 ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS (code=exited, status=1/FAILURE) Main PID: 1069 (code=exited, status=1/FAILURE) CPU: 209ms Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Main process exited, code=exited, status=1/FAILURE Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Failed with result 'exit-code'. Jul 08 16:13:25 haproxyxmail01 systemd[1]: Failed to start HAProxy Load Balancer. Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Scheduled restart job, restart counter is at 5. Jul 08 16:13:25 haproxyxmail01 systemd[1]: Stopped HAProxy Load Balancer. Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Start request repeated too quickly. Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Failed with result 'exit-code'. Jul 08 16:13:25 haproxyxmail01 systemd[1]: Failed to start HAProxy Load Balancer. And if I try to run my configuration from console Without sudo it fails And with sudo it works (See below) haproxy -d -f /etc/haproxy/haproxy.cfg Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result FAILED Total: 3 (2 usable), will use epoll. Available filters : [CACHE] cache [COMP] compression [FCGI] fcgi-app [ OT] opentracing [SPOE] spoe [TRACE] trace Using epoll() as the polling mechanism. [NOTICE] (1811) : haproxy version is 2.6.1-1ppa1~jammy [NOTICE] (1811) : path to executable is /usr/sbin/haproxy [ALERT](1811) : Binding [/etc/haproxy/haproxy.cfg:85] for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for [xx.xx.58.10:80] [ALERT](1811) : Binding [/etc/haproxy/haproxy.cfg:86] for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for [xx.xx.58.10:443] ... [ALERT](1811) : [haproxy.main()] Some protocols failed to start their listeners! Exiting. sudo haproxy -d -f /etc/haproxy/haproxy.cfg Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result FAILED Total: 3 (2 usable), will use epoll. Available filters : [CACHE] cache [COMP] compression [FCGI] fcgi-app [ OT] opentracing [SPOE] spoe [TRACE] trace Using epoll() as the polling mechanism. [WARNING] (1794) : Health check for server HA_DAG_XMail_Autodiscover/XMailDB02 succeeded, reason: Layer7 check pass
Re: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04
On 7/9/22 10:55, Willy Tarreau wrote: On Sat, Jul 09, 2022 at 12:03:02AM +0200, Vincent Bernat wrote: The error when not running as root is expected. However, the fact it does not work on boot, then works after is odd. Can you share a minimal configuration file which exhibits this issue? That's very strange, it sounds as if the service was not started as root. Was there any change in ubuntu 22 regarding the definition of what user a service starts under ? We did some debugging off-list and the IP addresses were handled by keepalived and ip_nonlocal_bind sysctl was not enabled.
Re: Server timeouts since HAProxy 2.2
On 2022-08-04 10:35, William Edwards wrote: However, https://haproxy.debian.net/#distribution=Debian&release=buster&version=2.2 says: "The Debian HAProxy packaging team provides various versions of HAProxy packages for use on different Debian or Ubuntu systems. The following wizard helps you to find the package suitable for your system. [...] You will get a stable release of HAProxy 2.2: you may not get the latest version but important fixes from later versions are included. Moreover, regressions are unlikely." The bugs page tries to get users to ALWAYS use the latest version. But the haproxy.debian.org page says that it's okay not to use the latest version. That's two different point of views, one from Debian, one from upstream. They are difficult to reconcile. That's why you (as a user) have to choose: an old version with only "important" fixes (security fixes mostly) and with known bugs but unlikely regressions on upgrade, or a recent version of a stable branch with fixes and sometimes regressions. Upstream is unlikely to help debug old versions. The Debian solution is to report the issue on bugs.debian.org, but this does not scale well and I am likely to just ignore the bug because I am too short on time. If 2.2.9 as in official Debian repository does not work for you, the easiest path is to upgrade to 2.2.25 using the second set of instructions. > I found this bug[1] on the bugs page which looks promising. I'll do > some more investigation today. Perhaps someone could corroborate that > that bug's symptoms match what I'm seeing. Note that if this patch fixes this bug, this is a lot of work to integrate it into the current release of Debian. This will have to wait for the next point release (not a security issue), I would need to ask people to authorize the patch, explain, ask again, prepare, upload, then upload the backports until you get the resulting package available as 2.2.9-2+deb11u4~bpo10+1. Backporting a random patch may trigger regressions as it may need other patches to be backported. This is a nest of problems. So, if this patch solves your issue, you are on your own maintaining a fork of the package. The commit mentioned in the patch (eddcfbc1911c when backported) is introduced in 2.2.23, so it's likely not the patch you need or you need other patches as well.
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On 2022-08-19 22:16, Ionel GARDAIS wrote: I had to rollback to 2.6.2 after having upgrade to 2.6.3 because systemd was restarting the haproxy process every 1m30s (on an up-to-date Debian 11) apt upgrade itself hung while doing the upgrade. With Debian packages from haproxy.debian.net? Logs from "journalctl -eu haproxy" should help.
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On 2022-08-19 23:09, Ionel GARDAIS wrote: Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : Failed to connect to the old process socket '/run/haproxy/admin.sock' Aug 19 22:09:09 haproxy-2 haproxy[1280]: [ALERT](1280) : Failed to get the sockets from the old process! There was a change in 2.6.0 (but not in 2.6.3) where "expose-fd listeners" for stats socket is not needed anymore. Is the line present in your configuration? (grep admin.sock /etc/haproxy/haproxy.cfg) What's the output of systemctl cat haproxy? Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : New worker (1282) forked Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : Loading success. Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check dur> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check dur> Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No r> Aug 19 22:09:09 haproxy-2 haproxy[1282]: [ALERT](1282) : backend 'bck-nuxeo-arch' has no server available! Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No route to host", check> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No route to host", check> Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server available! Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server available! […] // others few backends not responding // then Are these expected?
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On 2022-08-20 19:15, Ionel GARDAIS wrote: Below is the systemctl cat haproxy output. Yes, not responding backends was expected, sorry for not specified it. "expose-fd listeners" was present in the configuration file. Update fails even after I removed the two keywords. I have EXTRAOPTS="-x /run/haproxy/admin.sock" defined in /etc/defaults/haproxy This is the path referenced in the configuration file stats socket /run/haproxy/admin.sock mode 660 level admin The EXTRAOPTS in /etc/default/haproxy is ignored since quite some time (due to being overrided in the systemd file).
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On 2022-08-20 21:36, Ionel GARDAIS wrote: That was it : - remove the EXTRAOPTS from /etc/default/haproxy - stop the running process referencing -x /run/haproxy/admin.sock on the CLI - upgrade All is OK. First processes do not list -x on the CLI and a reload spawn a process with -x sockpair@ So, EXTRAOPTS is not ignored after all. I thought it would be overridden by the EXTRAOPTS set in the service file, but EnvironmentFile takes priority (despite being listed before), so that's the reverse situation.
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On 2022-08-20 22:35, Bren wrote: EnvironmentFile=-/etc/default/haproxy Do you have something here too? Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" This does not match the file shipped by HAProxy, but this may explain why you also run into this bug.
Re: SSL Certificate
On 2022-09-01 18:53, Илья Шипицин wrote: that website provides some non confidential documentation. neither it asks you for login/password or payment details. there's nothing wrong with http on such websites. There are download links without an obvious way to check for their integrity. HTTPS would at least protect against simple man in the middle. Or links should be to directory (but an attacker could hide the fact there are hash for the files then).
Re: Followup on openssl 3.0 note seen in another thread
On 2022-12-14 15:15, Willy Tarreau wrote: Possibly, yes. It's more efficient in every way from what we can see. For users who build themselves (and with QUIC right now you don't have a better choice), it should not change anything and will keep robustness. For those relying on the distro's package, I don't know if it's possible to install the previous distro's package side-by-side, but in any case it can start to become a mess to deal with. It's possible on Debian and I suspect this is the same for RedHat. However, you don't get security updates in this case.
Re: Followup on openssl 3.0 note seen in another thread
On 2022-12-16 05:49, Willy Tarreau wrote: There's currently a great momentum around WolfSSL that was already adopted by Apache, Curl, and Ngtcp2 (which is the QUIC stack that powers most HTTP/3-compatible agents). Its support on haproxy is making fast progress thanks to the efforts on the two sides, and it's pleasant to speak to people who care about performance. I'd bet we'll find it packaged in a usable state long before OpenSSL finally changes their mind on QUIC and reaches distros in a usable state. That's a perfect (though sad) example of the impact of design by committee! It's currently packaged in Debian and Ubuntu. For Ubuntu, it is currently in universe (no security support). For Debian, there are discussions to not ship it in the next release due to security concerns, but this is worked on. I'll ask again later when its support is finished in HAProxy if we can switch to it for Debian/Ubuntu packages. Next Debian will be using OpenSSL 3.0.0. Ubuntu is using OpenSSL 3.0.0 since Jammy.
Re: add-apt-repository ppa:vbernat/haproxy-2.7 fails
On 2023-01-05 18:23, Henning Svane wrote: TimeoutError: [Errno 110] Connection timed out Either your system does not have a connection to Internet or there was a transient error with Launchpad. Not much to do except retry a bit later.
Re: [*EXT*] Important HAProxy releases to come next week
On 2023-02-13 14:08, Thomas Pedoussaut wrote: That's a pretty sneaky way to ruin one's Valentine dinner. :-D Sure, but we have to compose between disclosing too early, ruining the west coast's morning and too late, ruining eastern dinners :-) Maybe this one will be remembered as the Valentine's bug. I think we're mostly good as it is now, but I'm still having some backports to finish for now. Do you know if Vincent Bernat will be publishing his PPA quickly afterwards ? Yes, I'll be ready.
Re: [*EXT*] Important HAProxy releases to come next week
On 2023-02-13 19:34, Vincent Bernat wrote: That's a pretty sneaky way to ruin one's Valentine dinner. :-D Sure, but we have to compose between disclosing too early, ruining the west coast's morning and too late, ruining eastern dinners :-) Maybe this one will be remembered as the Valentine's bug. I think we're mostly good as it is now, but I'm still having some backports to finish for now. Do you know if Vincent Bernat will be publishing his PPA quickly afterwards ? Yes, I'll be ready. For the Ubuntu PPA, there will be a small delay until the packages are built (I'll push the source at the disclosure time, but Launchpad will take a few minutes to build them). So, you should expect them a bit later.
Re: [*EXT*] RE: [ANNOUNCE] haproxy-2.4.22
On 2023-02-14 18:08, Ionel GARDAIS wrote: Hi Marc, I guess Vincent choose to use a -2 tag so that users who hold their package on minor version will still get the update. That's because the uploads were prepared in advance, before the 2.4.22 release. Willy sent us the patch in advance to be ready. The real 2.4.22 will likely be available tomorrow or the day after.
Re: process of release to debian, backports ?
For Debian stable, usually only a critical vulnerability. In theory, this could also be major bugs, but maintaining an hybrid patched version is something we prefer not to do, to not have people running in the wild an additional unsupported (by upstream) branch. For Debian backports, they should follow the version in testing. Sometimes (like now), I forget to upload the version once it reaches testing. Note that Debian backports may upgrade you to a new major version without much warning. On 2023-05-09 23:17, Jim Freeman wrote: Just Curious ... (probably a Vincent et al question?) What considerations/timings trigger gating an haproxy release getting into debian (and backports) archives ? Severity of problems fixed in release (e.g. CVE, ...) ? Available bandwidth/fatigue of uploaders ? Debian guidelines ? As always - gratitude and kudos to all for a stellar and useful system. ...jfree
Re: USE_QUIC in haproxy debian packages?
On 2023-11-22 09:13, William Lallemand wrote: Hello Vincent, [HAProxy list in cc] We backported the USE_QUIC_OPENSSL_COMPAT build option in HAProxy 2.8.4, so we can build with USE_QUIC using OpenSSL without a patched version of OpenSSL. Unfortunately we can't activate this option in the default build, because it's not compatible with other openssl libraries (quictls, libressl and boringssl don't use a specific build option). And using only a Makefile we can't really autodetect the libraries to activate an option. Do you think that's possible to activate these 2 options for the next 2.8 debian/ubuntu packages? Yes, I'll upload shortly, plus for jemalloc.
Re: Segfault on 2.1.3
❦ 3 mars 2020 15:34 -07, Sean Reifschneider : > We've been running haproxy 1.8 series for quite a while. We're currently > in the process of updating to 2.1, and have installed from the vbernat PPA > on Ubuntu 18.04 using the same old config file. > > Now we are seeing segfaults a few times a day: You can easily collect core information if you install systemd-coredump. Then, use "coredumpctl list" to locate the collected core, then "coredumpctl info XXX" to get some stack traces. If you install the -dbgsym package, you can also use "coredumpctl debug XXX" then use "bt full" and send the output. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
Re: Segfault on 2.1.3
❦ 4 mars 2020 13:19 -07, Sean Reifschneider : > I've upgraded back to 2.1, and installed the systemd-coredump, I'll update > when I have additional information. I wasn't able to find a -dbgsym > package, I even looked in the debian pool directory for the PPA. We're > talking like a haproxy-dbgsym package, right? Or am I missing > something? Sorry, I forgot to enable this option for 2.1 PPA. You should still be able to get tracebacks without the dbgsym package (with "coredumpctl info XXX"). -- Indent to show the logical structure of a program. - The Elements of Programming Style (Kernighan & Plauger)
Re: Segfault on 2.1.3
❦ 16 mars 2020 16:02 -06, Sean Reifschneider: > I reverted back to haproxy 2.0.13 from the PPA last Wednesday and have > verified that we get no segfaults on that. If there's anything else I can > provide for you, let me know. Otherwise I'm just gonna close this ticket > in our bugtracker. :-) Sorry, can't help you more. Maybe wait for the next release. It will get -dbgsym and it should provide more info on why you get the problem. -- Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain
Re: [PATCH] enable arm64 builds in travis-ci
❦ 8 mai 2020 14:25 +02, Willy Tarreau: >> > Let's increase the timeout to see if it has a chance to finish, no ? >> > >> >> yes > > OK now pushed. It's really annoying to work blindly like this. The > build model Travis uses is broken by design. Requiring to commit > something for testing is utterly wrong. And doing so within the > project that's supposed to being test is further wrong. We already > have 44 patches only on .travis.yml! If this continues like this, > I predict that a "pre-CI" solution will appear to test if your > change is likely to trigger a travis error before it gets merged... You can push changes to a (throwable) branch instead. -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
Re: Debian packaging note
❦ 28 mai 2020 12:48 +02, Tim Düsterhus: >> Okay, I've done what I really wanted to avoid and built my own HAProxy. >> I'm now running HAProxy 2.1.5-1~~~timwolla+1 and I hope that it will >> smoothly upgrade to Vincent's build once it is released. >> > > While researching how to build a 2.1.5 .deb based off your 2.1.4 sources > I noticed that Debian QA complained that HAProxy's compiler flags were > hidden [1]. You should be able to fix that by adjusting MAKEARGS in > debian/rules to include 'V=1': Thanks. I have added that for the next build on both 2.0 and 2.1. -- Patch griefs with proverbs. -- William Shakespeare, "Much Ado About Nothing"
Re: OSX builds in Travis
❦ 9 juillet 2020 13:12 +05, Илья Шипицин: > do you think does it make sense to use scripted brew instead of travis > plugin ? > > if so, we can try to "brew instal blah-blah-blah || ok, we failed, lets' > update and install one more time" I have also hit the problem several time. Brew upstream says to use "brew bundle" instead: #v+ -brew install libtool libxml2 check +brew bundle --file=- <<-EOS +brew "libtool" +brew "libxml2" +brew "check" +EOS #v- This way, brew doesn't complain if a requested package is already installed but not at the latest version. -- It is a wise father that knows his own child. -- William Shakespeare, "The Merchant of Venice"
Re: OSX builds in Travis
❦ 11 juillet 2020 00:48 +05, Илья Шипицин: > he-he, brew bundle is deprecated (does not work) > > https://apple.stackexchange.com/questions/148454/brew-bundle-reporting-error-unknown-command-bundle It's very old. It has been added back at some point. Here is upstream recommending its use: https://github.com/Homebrew/brew/issues/2491 However, as long as socat is not part of the packages already installed, just `brew install socat` should always work. -- It usually takes more than three weeks to prepare a good impromptu speech. -- Mark Twain
Re: OSX builds in Travis
❦ 11 juillet 2020 12:45 +05, Илья Шипицин: >> > he-he, brew bundle is deprecated (does not work) >> > >> > >> https://apple.stackexchange.com/questions/148454/brew-bundle-reporting-error-unknown-command-bundle >> >> It's very old. It has been added back at some point. Here is upstream >> recommending its use: https://github.com/Homebrew/brew/issues/2491 > > > https://travis-ci.com/github/chipitsine/haproxy/jobs/359964175#L133 It seems brew shipped by Travis is quite old. A `brew update` would fix this but then it adds 10 minutes to the build... So, back to square one. -- Nothing so needs reforming as other people's habits. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Re: Haproxy 2.2 LTS package for Debian Stretch oldstable
❦ 3 août 2020 22:29 +02, Artur: > It would be nice to have a Debian Stretch package for the current LTS > 2.2 branch in backports. It seems it's not available for now. Well, you are the second person asking this in a short time, so I will provide one. My rationale is that 2.2 is quite new and Stretch is already maintained as LTS. When maintained as LTS, we loose the ability to use backports (there is no LTS for official backports), so it may make the maintenance more difficult. However, it's unlikely the build system will change much during the lifecycle of the 2.2 and since it doesn't require backports, we should be fine. -- Parenthesise to avoid ambiguity. - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy 1.8.26-1~bpo9+1
❦ 4 août 2020 14:10 +02, Bram Gillemon:
> Running debian stretch with 1.8.25-1~bpo9+1, this morning the package
> upgraded to 1.8.26-1~bpo9+1 and i started noticing some strange
> behaviour.
For reference:
HA-Proxy version 1.8.26-1~bpo9+1 2020/08/03
Copyright 2000-2020 Willy Tarreau
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -O2 -fdebug-prefix-map=/build/haproxy-1.8.26=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-null-dereference -Wno-unused-label
OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1
USE_SYSTEMD=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_NS=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.0l 10 Sep 2019
Running on OpenSSL version : OpenSSL 1.1.0l 10 Sep 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE2 version : 10.22 2016-07-29
PCRE2 library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
--
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy 1.8.26-1~bpo9+1
❦ 5 août 2020 22:48 +02, Christopher Faulet: >> i was just setting up the 2.2 version again and i think i did >> something wrong this morning because i can't reproduce it anymore. >> >> Sorry for the extra work i caused. >> > No problem. I always prefer a false bug report than a long fix session :) Does this bug happens often? Will a new version be released "soon"? Should I update the packages with this patch? -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy 1.8.26-1~bpo9+1
❦ 4 août 2020 14:10 +02, Bram Gillemon: > Running debian stretch with 1.8.25-1~bpo9+1, this morning the package > upgraded to 1.8.26-1~bpo9+1 and i started noticing some strange > behaviour. I have uploaded 1.8.26-2 with the upstream fix included (for all supported distros). If you can check it also works for you... Thanks. -- Take care to branch the right way on equality. - The Elements of Programming Style (Kernighan & Plauger)
Re: HAProxy 2.2.2 CE issue report
❦ 24 août 2020 21:59 +03, Milen Simeonov: > frontend fe_main > bind 127.0.0.1:443 ssl crt-list /etc/haproxy/certs/websites.crt_list I am not able to reproduce. The configuration is missing a path to a certificate. Does it also crash if you don't provide a crt-list? -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy 2.2.3 source
❦ 8 septembre 2020 16:13 -04, Alex Evonosky: > Just compiling 2.2.3 and getting this reference: > > > /haproxy-2.2.3/src/thread.c:212: undefined reference to > `_Unwind_Find_FDE' I am getting the same issue on armhf only. Other platforms don't get this issue. On this platform, we only get: w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException So, older symbols are: 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the signature I have in glibc is: fde * _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases) -- Don't sacrifice clarity for small gains in "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy 2.2.3 source
❦ 9 septembre 2020 16:58 +02, Willy Tarreau: > Ah I'm really angry because I tested on many platforms, *including* armhf, > but now I'm not seeing it, so either I failed on one test or it depends > on the compiler combination :-( I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27). -- Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, "Endgame"
Re: Haproxy 2.2.3 source
It is not cross-built. Debian builds armhf from arm64 builders. It seems Ubuntu is also using arm64 hardware to build armhf. An alternative that could work is to use QEMU user emulation. You can directly use "qemu-debootstrap --arch=armhf" to get a working chroot. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger) ――― Original Message ――― From: Илья Шипицин Sent: 9 septembre 2020 20:38 +05 Subject: Re: Haproxy 2.2.3 source To: Willy Tarreau Cc: Vincent Bernat; Alex Evonosky; haproxy@formilux.org > how do you build armh ? can you share details ? > if that's cross build, we can easily add to github actions, for example. > > unfortunately, it is hard to get armh native CI. > > ср, 9 сент. 2020 г. в 20:01, Willy Tarreau : > >> On Tue, Sep 08, 2020 at 11:47:25PM +0200, Vincent Bernat wrote: >> > ? 8 septembre 2020 16:13 -04, Alex Evonosky: >> > >> > > Just compiling 2.2.3 and getting this reference: >> > > >> > > >> > > /haproxy-2.2.3/src/thread.c:212: undefined reference to >> > > `_Unwind_Find_FDE' >> > >> > I am getting the same issue on armhf only. Other platforms don't get >> > this issue. On this platform, we only get: >> > >> > w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx >> > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException >> > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase >> > 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace >> > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind >> > 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow >> > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase >> > 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set >> > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume >> > 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop >> > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart >> > 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete >> > 00017184 gDF .text 0012 GCC_3.0 >> _Unwind_GetLanguageSpecificData >> > 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get >> > 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA >> > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException >> > >> > So, older symbols are: >> > >> > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException >> > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase >> > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind >> > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase >> > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume >> > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart >> > 00017184 gDF .text 0012 GCC_3.0 >> _Unwind_GetLanguageSpecificData >> > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException >> > >> > Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the >> > signature I have in glibc is: >> > >> > fde * >> > _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases) >> >> Ah I'm really angry because I tested on many platforms, *including* armhf, >> but now I'm not seeing it, so either I failed on one test or it depends >> on the compiler combination :-( >> >> The principle was just to force to load libgcc_s that tends to cause >> aborts on reload for some users in chroots when threads exit, because >> pthread_exit() tends to be the first one to require libgcc_s and it's >> quite too late. >> >> In the mean time you can probably get away with this: >> >> diff --git a/src/thread.c b/src/thread.c >> index 5eb68e33a..167e26e9d 100644 >> --- a/src/thread.c >> +++ b/src/thread.c >> @@ -201,7 +201,7 @@ static void __thread_init(void) >> exit(1); >> } >> >> -#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) && >> !defined(__clang__) >> +#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) && >> !defined(__clang__) && !defined(__arm__) >> /* make sure libgcc_s is already loaded, because pthread_exit() may >> * may need it on exit after the chroot! _Unwind_Find_FDE() is >> defined >> * there since gcc 3.0, has no side effect, doesn't take any >> argument >> >> >> But I'd really like to find a *reliable* way to force libgcc_s to be loaded >> if available and required (i.e. not if statically built). I thought about >> causing a 64/64 bit divide that usually is done via divsi3 and friend but >> on x86_64 (where the problem was encountered) it will not do it. >> >> I'm thinking about something: maybe I can have a look around >> pthread_getspecific() and pthread_key_create(). I would be very surprised >> if they didn't rely on some compiler-specific help from libgcc_s. >> >> I'll keep testing and will get back to you guys. >> >> Willy >> >>
Re: Haproxy 2.2.3 source
❦ 9 septembre 2020 19:31 +02, Willy Tarreau: >> Feel free to pick this patch if that helps for your builds, I'm going >> to backport it to 2.2 once all platforms are happy. > > All builds are OK now, the commit was backported to 2.2 and the patch > can be retrieved here: > > http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab All good on Debian: https://buildd.debian.org/status/package.php?p=haproxy&suite=experimental -- Small things make base men proud. -- William Shakespeare, "Henry VI"
Re: haproxy conflict between debian backports and haproxy.debian.net
❦ 14 janvier 2021 07:39 +01, ghislain: > So, should i use basic debian backports or debian.haproxy.net > because having both seems to collide with a boom ;p ! It's not really a conflict, but yes, you have an unecessary "downgrade" to the same version as currently backports has 2.2.x. You can switch to Debian backports but in the future, it may get 2.4.x while haproxy.debian.net ensures you stay on 2.2.x. Alternatively, I will be careful next time to upload the same binary to haproxy.debian.net and to Debian backports. Also, you seem to have a custom /etc/apt/preferences that may explain why you are the first to notice that? -- The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain
Re: haproxy conflict between debian backports and haproxy.debian.net
❦ 14 janvier 2021 19:24 +01, Tim Düsterhus: > I just checked haproxy.debian.net and noticed that the information > regarding the backports is not up to date: > > For Debian Buster the backport should be moved from 2.0 to 2.2. > > I'd also like to note that you have a typo in haproxy.js. It says > 'backport+' instead of 'backports+' (missing 's'). Oh, thanks! Both issues are fixed! -- Make input easy to prepare and output self-explanatory. - The Elements of Programming Style (Kernighan & Plauger)
Re: Packaging hatop for ubuntu20.04
❦ 3 février 2021 10:23 GMT, Louis Charreau: > we use hatop daily to monitor in real time haproxy. > This tool is no longer packaged in ubuntu 20.04 (LTS), which is a pity for > such a useful tool. > > It's true that the initial project doesn't seem to be maintained > anymore (last commit 5 years ago) and only works in Python2 which is > itself deprecated: feurix/hatop (https://github.com/feurix/hatop). > > We referred to the jhunt/hatop project > (https://github.com/jhunt/hatop), which is compatible with Python2 and > 3. And we integrated it into our private repositories. > > Do you think it would be possible and useful for others to reintegrate > hatop into the official Debian / Ubuntu repositories? It's already the case: https://tracker.debian.org/news/1226222/accepted-hatop-080-1-source-all-into-unstable-unstable/ -- Write clearly - don't be too clever. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-1.6.16
❦ 19 mars 2021 17:34 +01, Christopher Faulet: > HAProxy 1.6.16 was released on 2021/03/19. It added 71 new commits > after version 1.6.15. 1.6 was EOL last year, I don't understand why there is a last release. Both 1.6 and 1.7 are marked for critical fixes but many fixes are pushed in it. The risk is to introduce a late regression in this last version. -- Make sure your code "does nothing" gracefully. - The Elements of Programming Style (Kernighan & Plauger)
Re: Table sticky counters decrementation problem
❦ 30 mars 2021 11:21 +02, Thomas SIMON: > And I confirm you than when rolling back with source compilation and > 2.3.7 version (can't do this with repository as only last version is > available) , counters decrements well. The old debs are still here, so you can still download them manually if you need to. I need to switch to aptly at some point since reprepro is unlikely to ever support several versions for the same source package. I would also have to host and build packages for Ubuntu as well as it is common request. -- Choose variable names that won't be confused. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-2.3.9
❦ 31 mars 2021 10:35 +02, Willy Tarreau: >> Thanks Willy for the quick update. That's a good example to avoid >> pushing stable versions at the same time, so we have opportunities to >> find those regressions. > > I know and we're trying to separate them but it considerably increases the > required effort. In addition there is a nasty effect resulting from shifted > releases, which is that it ultimately results in older releases possibly > having more recent fixes than recent ones. And it will happen again with > 2.2.12 which I hope to issue today. It will contain the small fix for the > silent-drop issue (which is already in 2.3 of course) but was merged after > 2.3.9. The reporter of the issue is on 2.2, it would not be fair to him to > release another 2.2 without it (or we'd fall into a bureaucratic process > that doesn't serve users anymore). So 2.2.12 will contain this fix. But > if the person finally decides to upgrade to 2.3.9 a week or two later, she > may face the bug again. It's not a dramatic one so that's acceptable, but > that shows the difficulties of the process. It's a bit annoying that fixes reach a LTS version before the non-LTS one. The upgrade scenario is one annoyance, but if there is a regression, you also impact far more users. You could tag releases in git (with -preX if needed) when preparing the releases and then issue the release with a few days apart. Users of older versions will have less frequent releases in case regressions are spotted, but I think that's the general expectation: if you are running older releases it's because you don't have time to upgrade and it's good enough for you. For example: - 2.3, monthly release or when there is a big regression - 2.2, 3 days after 2.3 - 2.0, 3 days after 2.2, skip one out of two releases - 1.8, 3 days after 2.0, skip one out of four releases So, you have a 2.3.9. At the same time, you tag 2.2.12-pre1 (to be released in 3 working days if everything is fine) and you skip skip 2.0 and 1.8 this time because they were releases to match 2.3.8. Next time, you'll have a 2.0.22-pre1 but no 1.8.30-pre1 yet. If for some reason, there is an important regression in 2.3.9 you want to address, you release a 2.3.10 and a 2.2.12-pre2, still no 2.0.22-pre1 nor 1.8.30-pre1. Hopefully, no more regressions spotted, you tag 2.2.12 on top of 2.2.12-pre2 and issue a release. -- He hath eaten me out of house and home. -- William Shakespeare, "Henry IV"
Re: [ANNOUNCE] haproxy-2.3.9
❦ 31 mars 2021 12:46 +02, Willy Tarreau: > On the kernel Greg solved all this by issuing all versions very > frequently: as long as you produce updates faster than users are > willing to deploy them, they can choose what to do. It just requires > a bandwidth that we don't have :-/ Some weeks several of us work full > time on backports and tests! Right now we've reached a point where > backports can prevent us from working on mainline, and where this lack > of time increases the risk of regressions, and the regressions require > more backport time. Wouldn't this mean there are too many versions in parallel? > I think that the real problem arrives when a version becomes generally > available in distros. And distro users are often the ones with the least > autonomy when it comes to rolling back. When you build from sources, > you're more at ease. Thus probably that a nice solution would be to > add an idle period between a stable release and its appearance in > distros so that it really gets some initial deployment before becoming > generally available. And I know that some users complain when they do > not immediately see their binary package, but that's something we can > easily explain and document. We could even indicate a level of confidence > in the announce messages. It has the merit of respecting the principle > of least surprise for everyone in the chain, including those like you > and me involved in the release cycle and who did not necessarily plan > to stop all activities to work on yet-another-release because the > long-awaited fix-of-the-month broke something and its own fix broke > something else. We can do that. In the future, I may even tackle all the problems at once: providing easy access to old versions and have two versions of each repository: one with new versions immediately available and one with a semi-fixed delay. -- April 1 This is the day upon which we are reminded of what we are on the other three hundred and sixty-four. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Re: Proposal about libslz integration into haproxy
❦ 21 avril 2021 08:04 +02, Willy Tarreau: > William suggested that I was needlessly seeking for trouble and that it > was pointless to keep compatibility for *both* an external version and > an internal one. While I initially wanted to demonstrate him he was wrong, > I realized that I was the one wrong because the lib had considerably > stabilized (no change over one year), and after all we already embed a > few other things like xxhash and ebtree without offering the possibility > to build with an external variant, and in the end it probably was the > right solution. > > So after changing my mind, I would go with the following approach: > > - building with USE_SLZ=1 => always use the embedded one > - building with USE_ZLIB=1 => always build using the user-provided zlib > > We'd enable USE_SLZ by default and it would be disabled when ZLIB is used > (or when SLZ is forced off). This way we could have fast and memory-less > compression available by default without the hassle of cloning an unknown > repository. > > Does anyone have any opinion, objection or suggestion on this (especially > those in CC who participated to the first discussion or who could have > packaging concerns) ? Barring any comment I think I'm going to do this > tomorrow so that we have it in -dev17, leaving a bit of time for distro > packagers to test and adjust their build process if needed. >From a distribution point of view, we don't like bundled dependencies. However, as I see it, libslz is an internal lib (like ebtree), so I don't think this is really a problem. Moreover, we don't have the external lib in Debian, so there is no duplicate work. Is there any practical advantage of keeping using zlib (for a user)? -- Test programs at their boundary values. - The Elements of Programming Style (Kernighan & Plauger)
[PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully
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 b/src/stick_table.c
index 7a2fcc21af8b..2d5c042174fb 100644
--- a/src/stick_table.c
+++ b/src/stick_table.c
@@ -170,7 +170,10 @@ struct stksess *stksess_new(struct stktable *t, struct
stktable_key *key)
return NULL;
}
- ts = pool_alloc2(t->pool) + t->data_size;
+ ts = pool_alloc2(t->pool);
+ if (unlikely(ts == NULL))
+ return NULL;
+ ts += t->data_size;
if (ts) {
t->current++;
stksess_init(t, ts);
--
2.10.2
[PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully
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/src/stick_table.c
index 7a2fcc21af8b..7026fe65659a 100644
--- a/src/stick_table.c
+++ b/src/stick_table.c
@@ -170,9 +170,10 @@ struct stksess *stksess_new(struct stktable *t, struct
stktable_key *key)
return NULL;
}
- ts = pool_alloc2(t->pool) + t->data_size;
+ ts = pool_alloc2(t->pool);
if (ts) {
t->current++;
+ ts += t->data_size;
stksess_init(t, ts);
if (key)
stksess_setkey(t, ts, key);
--
2.10.2
Re: [PATCH] BUG/MINOR: stick-table: handle out-of-memory condition gracefully
❦ 17 novembre 2016 15:14 +0100, Willy Tarreau :
> Good catch, but look the original if intented to catch this but was
> wrong, thus I think it's better to remove it now :
>
>> ---
>> src/stick_table.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/stick_table.c b/src/stick_table.c
>> index 7a2fcc21af8b..2d5c042174fb 100644
>> --- a/src/stick_table.c
>> +++ b/src/stick_table.c
>> @@ -170,7 +170,10 @@ struct stksess *stksess_new(struct stktable *t, struct
>> stktable_key *key)
>> return NULL;
>> }
>>
>> -ts = pool_alloc2(t->pool) + t->data_size;
>> +ts = pool_alloc2(t->pool);
>> +if (unlikely(ts == NULL))
>> +return NULL;
>> +ts += t->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
Re: [ANNOUNCE] haproxy-1.5.19
❦ 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: Thu Oct 8 11:32:32 2015 +0200 MEDIUM: init: support more command line arguments after pid list Given that all command line arguments start with a '-' and that no pid number can start with this character, there's no constraint to make the pid list the last argument. Let's relax this rule. This would enable to use the same init scripts for both 1.5 and 1.6. -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-1.5.19
❦ 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 c6ca1aa34dd0e343c9a8754f447730b7563d > Author: Willy Tarreau > Date: Thu Oct 8 11:32:32 2015 +0200 > > MEDIUM: init: support more command line arguments after pid list > > Given that all command line arguments start with a '-' and that > no pid number can start with this character, there's no constraint > to make the pid list the last argument. Let's relax this rule. > > This would enable to use the same init scripts for both 1.5 and 1.6. On the other hand, this is not really useful without a088d316. So, maybe don't introduce another bug because of me and leave 1.5 as is. :) -- Repartee is something we think of twenty-four hours too late. -- Mark Twain
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 c6ca1aa34dd0e343c9a8754f447730b7563d >> > Author: Willy Tarreau >> > Date: Thu Oct 8 11:32:32 2015 +0200 >> > >> > MEDIUM: init: support more command line arguments after pid list >> > >> > Given that all command line arguments start with a '-' and that >> > no pid number can start with this character, there's no constraint >> > to make the pid list the last argument. Let's relax this rule. >> > >> > This would enable to use the same init scripts for both 1.5 and 1.6. >> >> On the other hand, this is not really useful without a088d316. So, maybe >> don't introduce another bug because of me and leave 1.5 as is. :) > > Well, neither of them are hard to backport, so this is something we can > consider. However I'm making a difference between end-users requests and > maintainers' convenience. If you think it would really be useful to end > users one way or another, or if it solves some trouble you're facing > with the package maintenance, let's backport them. If it's just to keep > a single script to maintain, I think the benefit is low enough to avoid > a backport. Just let me know what you prefer, I'm fine with both > options. I got caught by syncing SysV init script from 1.6 with 1.5. For my own convenience, only c6ca1aa is needed. But I think that I won't be caught again by this since the only diff is the argument order. I should be able to remember why this is like that! So, no need from me. -- Many pages make a thick book.
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 notice > chroot /var/lib/haproxy > > > and rsyslog is: > > # Create an additional socket in haproxy's chroot in order to allow > logging via > # /dev/log to chroot'ed HAProxy processes > $AddUnixListenSocket /var/lib/haproxy/dev/log > > # Send HAProxy messages to a dedicated logfile > if $programname startswith 'haproxy' then /var/log/haproxy.log > &~ > > > Am I missing something obvious? The package doesn't reload rsyslog for you (more recent versions of the rsyslog package will do that). Does /var/lib/haproxy/dev/log exist? -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare
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 1-10 TCP connections, sometimes just 1 - a >> stale connection that does not seem to belong to any frontend >> session. Strace with -T shows the folllowing: > > In fact a few bugs have caused this situation and all known ones were > fixed, which doesn't mean there is none left of course. However your > version is totally outdated and contains tons of known bugs which were > later fixed (196 total, 22 major, 78 medium, 96 minor) : > >http://www.haproxy.org/bugs/bugs-1.6.3.html Those pages are quite useful! That's the version in Ubuntu Xenial. It is possible to add some patches and push a new release. However, we have to select the patches (all the MAJOR ones?) and create this hybrid version. It could be useful for people not allowed to use third party packages (like the ones on haproxy.debian.net) or for those that just don't know they exist. While I think this would be useful for many, the gap is so wide that it even seems risky. If we are able to identify a couple of patches, I can walk the process of pushing them. This version is in Ubuntu because this was the version in Debian unstable a few months before the freeze. It's always a bit random as we (in Debian) don't really care about that when choosing the version we push in unstable (we care about our own release). FYI, we are likely to release 1.7.5 (with USE_GETADDRINFO=1 enabled) in our next release (to happen in July I hope). -- There's small choice in rotten apples. -- William Shakespeare, "The Taming of the Shrew"
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 patch going into a stable release MUST be applied. > What is considered major for some has no impact for others and what is > minor for some is business critical for others. In all cases it ends up > with reports here on the list. While there exists some exceptions, the rule of thumb in distributions is to stick to a version and backport only very critical (and security) patches. While this creates some friction with upstreams, this seems to match the expectation of many users (no random breakages during upgrades). This is a bit unfair to you since you maintain a bugfix-only branch which is also the goal we have (we just have more draconian rules about the accepted patches). I said there are exceptions (maybe 5 packages) where packages are kept up-to-date with the latest version of a branch, but they only apply to unfriendly upstreams (Oracle for example). I let you draw any conclusion on that. :) In Debian, we have acknowledged a long time ago this doesn't fit the need of all our users, so we have official backports. Ubuntu has them also but this is not widely used (Trusty got a backport for HAProxy 1.5.14 because they needed it for a customer). >> FYI, we are likely to release 1.7.5 (with USE_GETADDRINFO=1 enabled) in >> our next release (to happen in July I hope). > > Do you think there's an opportunity to get 1.7.6 if I release it next week ? > It provides -fwrapv which will likely avoid certain bugs with more recent > compilers, and there's a fix for a segfault in Lua. We need to take the decision with the release team. We are in freeze since January but we were able to push the latest version nonetheless. I think it is likely we will be able to push 1.7.6 as well. Otherwise, we'll push the patches marked "BUG/MAJOR" (this is what we have done with 1.5.8 currently in Jessie, this is 1.5.8 + patches from 1.5.9 and 1.5.10 + a security patch). -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger)
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 check if it fixes your bug (it should >> > do so) ? >> > >> > It was not backported in 1.7 because we thought it only affected the >> > 1.8. I will check with Willy. >> >> Thanks, patch fixes the problem (with test config (I'll try to >> test with prod. config later)). >> >> -Jarno >> > > Thanks for tests, I will backport it in the 1.7 branch. Is the patch important enough to warrant a 1.7.7 soon? Notably, should downstreams continue to push 1.7.6 to users? -- Parenthesise to avoid ambiguity. - The Elements of Programming Style (Kernighan & Plauger)
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 strace pid 2677 on this screenshot :
> $ strace -p 2677
> strace: Process 2677 attached
> epoll_wait(0, [], 200, 18) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 12) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 14) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 13) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 121) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 6) = 0
> epoll_wait(0, [], 200, 0) = 0
> epoll_wait(0, [], 200, 22) = 0
>
> if I check what's going on on the network level for this pid :
> $ ss -lntpuae |grep -i 'pid=2677'
> udpUNCONN 0 0 *:28382
> *:*
> users:(("haproxy",pid=2677,fd=14),("haproxy",pid=2611,fd=14))
> ino:1822334707 sk:aa61 -->
For information, haproxy -vv is:
HA-Proxy version 1.7.5-2 2017/05/17
Copyright 2000-2017 Willy Tarreau
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -g -O2 -fdebug-prefix-map=/build/haproxy-2dHYaz/haproxy-1.7.5=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2
OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1
USE_PCRE=1 USE_NS=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.1.0e 16 Feb 2017
Running on OpenSSL version : OpenSSL 1.1.0f 25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with network namespace support
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available filters :
[COMP] compression
[TRACE] trace
[SPOE] spoe
On your screenshot, the user is www-data while on lsof, this is
haproxy. Handover between HAProxy instances is done through signal,
maybe you reloaded the configuration with a change of user. The new
HAProxy cannot signal the old one to shutdown in this case. However,
this wouldn't explain why lsof and htop don't agree.
--
Fame is a vapor; popularity an accident; the only earthly certainty is
oblivion.
-- Mark Twain
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 strace. Unfortunately, I don't have any other clue. Maybe someone else could help. Otherwise, you can also try to upgrade to the latest upstream version to check if this has been fixed. You can grab a more recent version from https://haproxy.debian.net. -- Don't diddle code to make it faster - find a better algorithm. - The Elements of Programming Style (Kernighan & Plauger)
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 | http://debian.mirrors.ovh.net/debian > stretch-backports/main amd64 Packages >haproxy | 1.7.8-1~bpo9+1 | http://ftp.fr.debian.org/debian > stretch-backports/main amd64 Packages >haproxy |1.7.5-2 | http://debian.mirrors.ovh.net/debian > stretch/main amd64 Packages >haproxy | 1.7.8-1~bpo9+1 | http://debian.mirrors.ovh.net/debian > stretch-backports/main Sources >haproxy |1.7.5-2 | http://debian.mirrors.ovh.net/debian > stretch/main Sources > ii haproxy 1.7.5-2 > amd64fast and reliable load balancing reverse proxy > ii vim-haproxy 1.7.5-2 > all syntax highlighting for HAProxy configuration files > > This stale process issue is quite a mystery atm. It depends what you call upstream. :) My suggestion was to try 1.7.8 (through the backports for example). -- Patch griefs with proverbs. -- William Shakespeare, "Much Ado About Nothing"
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 succeeds or not. You can use the "official" backport from Debian repositories. You just have to know it could be updated to 1.8 at some point (while the packages served directly by haproxy.debian.net won't). -- Document your data layouts. - The Elements of Programming Style (Kernighan & Plauger)
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 sp > 7ffe1d613488 error 4 in libc-2.24 > > Can you please help or have any ideas? Try to obtain a core file: - don't use chroot directive in /etc/haproxy/haproxy.cfg - sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%h.%t - systemctl edit haproxy.service and put the following: [Service] LimitCORE=infinity - systemctl daemon-reload - systemctl restart haproxy Check with "cat /proc/$(pidof haproxy | head -1)/limits" both limits for "core file size" is unlimited. Once you get a core file in /tmp/core.haproxy.something, use: - apt-get install haproxy-dbgsym libc6-dbg gdb - gdb /usr/sbin/haproxy /tmp/core.haproxy.something - bt full (post the result) To reverse your system: - apt-get remove haproxy-dbgsym libc6-dbg gdb - rm /etc/systemd/system/haproxy.service.conf.d/something.conf - systemctl daemon-reload - sysctl -w kernel.core_pattern=core -- How apt the poor are to be proud. -- William Shakespeare, "Twelfth-Night"
Re: Haproxy segfault error 4 in libc-2.24
Hello, Not sure to understand. Is there no core dump or more than one? If none, did you check in /proc/xxx/status that the limit was correctly applied? -- Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & 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 > core file dumped in /tmp/. > > running gdb console it only says "[Inferior 1 (process 719) exited > normally]" when the segfault error occours and haproxy restarts. bt > and bt full results in "No stack." > > Can you help about this? > > kind regards, > > marcus > > > Am 02.10.2017 um 11:35 schrieb 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 sp >>> 7ffe1d613488 error 4 in libc-2.24 >>> >>> Can you please help or have any ideas? >> Try to obtain a core file: >> >> - don't use chroot directive in /etc/haproxy/haproxy.cfg >> - sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%h.%t >> - systemctl edit haproxy.service and put the following: >> >> [Service] >> LimitCORE=infinity >> >> - systemctl daemon-reload >> - systemctl restart haproxy >> >> Check with "cat /proc/$(pidof haproxy | head -1)/limits" both limits for >> "core file size" is unlimited. >> >> Once you get a core file in /tmp/core.haproxy.something, use: >> >> - apt-get install haproxy-dbgsym libc6-dbg gdb >> - gdb /usr/sbin/haproxy /tmp/core.haproxy.something >> - bt full (post the result) >> >> To reverse your system: >> >> - apt-get remove haproxy-dbgsym libc6-dbg gdb >> - rm /etc/systemd/system/haproxy.service.conf.d/something.conf >> - systemctl daemon-reload >> - sysctl -w kernel.core_pattern=core
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 popularize literature? -- Nero Wolfe, "The League of Frightened Men"
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 core files in this directory (keep core_pattern to /tmp/...). -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy segfault error 4 in libc-2.24
Then, remove the chroot directive from HAProxy configuration. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger) ――― Original Message ――― From: Marcus Ulbrich Sent: 2 octobre 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, 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 core_pattern to >> /tmp/...).
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 kernel.core_pattern ls -ld /var/lib/haproxy/tmp -- Use the "telephone test" for readability. - The Elements of Programming Style (Kernighan & Plauger)
Re: Haproxy segfault error 4 in libc-2.24
Well, I have no idea why you don't get those core files. It's also quite
odd that you get chrooted without the chroot directive. Maybre 'rgrep
chroot /etc' to check if there is anything fishy. Is there anything
special in your environment? Running in a container with memory limits
maybe?
To be sure the core pattern works correctly, could you run:
ulimit -c unlimited
python -c 'import os,time; os.chroot("/var/lib/haproxy"); time.sleep(1000)' &
kill -SEGV %1
You should get a "segmentation fault (core dumped)" and a core file in
/var/lib/haproxy/tmp. If not, check in /tmp directly (on my system, I
didn't get the core file in the chroot, this is new to me). If it
doesn't work, try without os.chroot() and check you get a core file in
/tmp.
--
All things that are, are with more spirit chased than enjoyed.
-- 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
>
> kernel.core_pattern = /tmp/core.%e.%p.%h.%t
>
> $# ls -ld /var/lib/haproxy/tmp
>
> drwxrwxrwt 2 root root 4096 Okt 2 16:11 /var/lib/haproxy/tmp
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 with just "core", the core file should be in the current directory. If it works, retry with HAProxy and you should get the core in /var/lib/haproxy. -- Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & Plauger)
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". Do you get it? If yes, do you get it too with:
python -c 'import os,time; os.chroot("/var/lib/haproxy"); os.chdir("/");
time.sleep(1000)' &
kill -SEGV %1
It should be in /var/lib/haproxy/tmp. If yes, you should get it with
HAProxy too.
--
So so is good, very good, very excellent good:
and yet it is not; it is but so so.
-- William Shakespeare, "As You Like It"
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 wrote: >no chance... error or killing haproxy there is no core file there... >wether in /var/lib, nor in /tmp >I am frustrated...
Re: Haproxy segfault error 4 in libc-2.24
Could you get another one with libssl1.1-dbgsym installed? But just with
that, maybe other people could infer what's wrong.
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
――― Original Message ―――
From: Marcus Ulbrich
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.
>
> __memmove_sse2_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:
>
> ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:
> File or Directory not found.
>
>
> (gdb) bt
>
> #0 0x7ff59a39f760 in __write_nocancel () at
> ../sysdeps/unix/syscall-template.S:84
>
> #1 0x7ff59abc4a45 in ?? () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> #2 0x7ff59abbf58b in BIO_write () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> #3 0x7ff59afbfa4b in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #4 0x7ff59afc0260 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #5 0x7ff59afc8751 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #6 0x7ff59afc6b55 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #7 0x7ff59afd0cd9 in SSL_shutdown () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #8 0x55bfb883e6b9 in ssl_sock_shutw (conn=0x55bfb9edf9f0,
> clean=)
>
> at src/ssl_sock.c:3923
>
> #9 0x55bfb8801696 in conn_data_shutw (c=) at
> include/proto/connection.h:437
>
> #10 stream_int_shutw_conn (si=0x55bfb9e80798) at src/stream_interface.c:856
>
> #11 0x55bfb8802c8b in si_shutw (si=0x55bfb9e80798) at
> include/proto/stream_interface.h:322
>
> #12 stream_int_notify (si=si@entry=0x55bfb9e80798) at
> src/stream_interface.c:459
>
> #13 0x55bfb8802ecd in si_conn_wake_cb (conn=0x55bfb9edf9f0) at
> src/stream_interface.c:581
>
> #14 0x55bfb87dde3a in conn_fd_handler (fd=) at
> src/connection.c:158
>
> #15 0x55bfb87aae5d in fd_process_cached_events () at src/fd.c:223
>
> #16 0x55bfb8799638 in run_poll_loop () at src/haproxy.c:1751
>
> #17 0x55bfb87958a9 in main (argc=, argv= out>) at src/haproxy.c:2114
>
>
> (gdb) bt full
>
> #0 0x7ff59a39f760 in __write_nocancel () at
> ../sysdeps/unix/syscall-template.S:84
>
> No locals.
>
> #1 0x7ff59abc4a45 in ?? () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> No symbol table info available.
>
> #2 0x7ff59abbf58b in BIO_write () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> No symbol table info available.
>
> #3 0x7ff59afbfa4b in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #4 0x7ff59afc0260 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #5 0x7ff59afc8751 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #6 0x7ff59afc6b55 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #7 0x7ff59afd0cd9 in SSL_shutdown () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #8 0x55bfb883e6b9 in ssl_sock_shutw (conn=0x55bfb9edf9f0,
> clean=) at src/ssl_sock.c:3923
>
> clean =
>
> conn = 0x55bfb9edf9f0
>
> #9 0x55bfb8801696 in conn_data_shutw (c=) at
> include/proto/connection.h:437
>
> No locals.
>
> #10 stream_int_shutw_conn (si=0x55bfb9e80798) at src/stream_interface.c:856
>
> No locals.
>
> #11 0x55bfb8802c8b in si_shutw (si=0x55bfb9e80798) at
> include/proto/stream_interface.h:322
>
> No locals.
>
> #12 stream_int_notify (si=si@entry=0x55bfb9e80798) at
> src/stream_interface.c:459
>
> No locals.
>
> #13 0x55bfb8802ecd in si_conn_wake_cb (conn=0x55bfb9edf9f0) at
> src/stream_interface.c:581
>
> si = 0x55bfb9e80798
>
> #14 0x55bfb87dde3a in conn_fd_handler (fd=) at
> src/connection.c:158
>
> conn = 0x55bfb9edf9f0
>
> flags =
>
> #15 0x55bfb87aae5d in fd_process_cached_events () at src/fd.c:223
>
> fd = 22
>
> entry = 0
>
> e =
>
> #16 0x55bfb8799638 in run_poll_loop () at src/haproxy.c:1751
>
> next =
>
> #17 0x55bfb87958a9 in main (argc=, argv= out>) at src/haproxy.c:2114
>
> err =
>
> retry =
>
> limit = {rlim_cur = 8046, rlim_max = 8046}
>
> errmsg =
> "\000\000\000\000\000\000\000\000\340\230\273\271\277U\000\000
> !\271P\374\177\000\000\350
> \271P\374\177\000\000\006\000\000\000\000\000\000\000\064\357\063\232\365\177\000\000
> !\271P\374\177\000\000 F\273\271\277U\000\000\000\313
> \233\365\177\000\000\256\215ǚ\365\177\000\000>\001\000\024\000\000\000\000\000bca\304h\347Kh\371",
>
>
> pidfd =
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: https://wiki.debian.org/AutomaticDebugPackages -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan & Plauger)
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 would help. It seems that one HTTP ACL is not working as expected. -- Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain
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). -- By trying we can easily learn to endure adversity. Another man's, I mean. -- Mark Twain
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 commenting all acl for testing. Is there no way to see > what acl was active, when haproxy crashes? While in gdb, you are likely to be able to do, but I can't say exactly how. Just with the information you provided, I think other people are more likely to pinpoint the ACL triggering the code path you get and the cause. Of course, you can also comment all ACL one by one until crash disappear. This would also help. -- Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan & Plauger)
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 you can do "env CC=clang make TARGET=...". Doesn't this work for you? -- O, what a tangled web we weave, When first we practice to deceive. -- Sir Walter Scott, "Marmion"
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 thing "?=" is that you can do "env >> CC=clang make TARGET=...". >> >> Doesn't this work for you? >> > > 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). -- Consider well the proportions of things. It is better to be a young June-bug than an old bird of paradise. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
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 Makefile -exec grep -E '^CC' {} ';' -print
> CC = gcc
> ./Makefile
> CC = gcc
> ./contrib/debug/Makefile
> CC = gcc
> ./contrib/halog/Makefile
> CC = gcc
> ./contrib/ip6range/Makefile
> CC = gcc
> ./contrib/iprange/Makefile
> CC ?= gcc
> ./contrib/mod_defender/Makefile
> CC ?= gcc
> ./contrib/modsecurity/Makefile
> CC = gcc
> ./contrib/spoa_example/Makefile
> CC = gcc
> ./contrib/tcploop/Makefile
Oh, I didn't understand. I think ?= should just be =.
--
Your manuscript is both good and original, but the part that is good is not
original and the part that is original is not good.
-- Samuel Johnson
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, this will still trigger
the dialog box to get a certificate from the user. AFAIK, there is no
way to achieve what Apache is doing using HAProxy: there is no code to
change SSL parameters after initial bind.
--
If you tell the truth you don't have to remember anything.
-- Mark Twain
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 Dream"
Re: DNS resolution issue with Docker swarm and HAProxy 1.8.15/1.9.0
❦ 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. > Thanks for fixing this one, Jérôme. Is it important enough for an 1.8.16? Is it important enough for distributors to release a fixed version? Why doesn't it affect most DNS implementations? -- There is no distinctly native American criminal class except Congress. -- Mark Twain
Re: haproxy segfault
❦ 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 configuration if it's enabled. Also, you need to set the core pattern to a fixed directory where haproxy user can write to, like: sysctl -w kernel.core_pattern=/tmp/core.%p Then, on next segfault, you should get your coredump. -- Let me take you a button-hole lower. -- William Shakespeare, "Love's Labour's Lost"
Re: [ANNOUNCE] haproxy-1.8.20
❦ 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 don't think it would be possible to push 1.8.20 as is. We can either keep 1.8.19 as is or select a few critical patches to apply on it. For example, we could take the MAJOR patches: BUG/MAJOR: checks: segfault during tcpcheck_main BUG/MAJOR: http_fetch: Get the channel depending on the keyword used BUG/MAJOR: listener: Make sure the listener exist before using it. BUG/MAJOR: spoe: Fix initialization of thread-dependent fields BUG/MAJOR: stats: Fix how huge POST data are read from the channel And maybe: BUG/MEDIUM: listener: make sure the listener never accepts too many conns The more changes, the less likely the release team will accept the change. Assuming we can only make one proposition (which is not true), what would you (as upstream) try? 1.8.19, one bug, all major bugs, even more bugs, or 1.8.20? -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger)
Re: [ANNOUNCE] haproxy-1.8.20
❦ 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 to encourage every user to switch to your up to > date PPA than making them believe their version contains the essential > fixes, which would be misleading. OK, I have just asked our release team if they would accept 1.8.20 as is. Let's see! -- Replace repetitive expressions by calls to a common function. - The Elements of Programming Style (Kernighan & Plauger)
