Re: USE_QUIC in haproxy debian packages?

[Vincent Bernat]

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: process of release to debian, backports ?

[Vincent Bernat]

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: [*EXT*] RE: [ANNOUNCE] haproxy-2.4.22

[Vincent Bernat]

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: [*EXT*] Important HAProxy releases to come next week

[Vincent Bernat]

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*] Important HAProxy releases to come next week

[Vincent Bernat]

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: add-apt-repository ppa:vbernat/haproxy-2.7 fails

[Vincent Bernat]

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: Followup on openssl 3.0 note seen in another thread

[Vincent Bernat]

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: Followup on openssl 3.0 note seen in another thread

[Vincent Bernat]

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: SSL Certificate

[Vincent Bernat]

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: [*EXT*] [ANNOUNCE] haproxy-2.6.3

[Vincent Bernat]

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: [*EXT*] [ANNOUNCE] haproxy-2.6.3

[Vincent Bernat]

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

[Vincent Bernat]

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

[Vincent Bernat]

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

[Vincent Bernat]

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: Server timeouts since HAProxy 2.2

[Vincent Bernat]

On 2022-08-04 10:35, William Edwards wrote:

However, 
https://haproxy.debian.net/#distribution=Debian=buster=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: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04

[Vincent Bernat]

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: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04

[Vincent Bernat]

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 passed, code: 200, check

Re: SV: Config will not start on 2.6.1 on Ubuntu 22.04

[Vincent Bernat]

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: Config will not start on 2.6.1 on Ubuntu 22.04

[Vincent Bernat]

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: [ANNOUNCE] haproxy-2.6.0

[Vincent Bernat]

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: [ANNOUNCE] haproxy-2.6.0

[Vincent Bernat]

 ❦ 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: [PATCH 1/1: BUILD/MINOR: TCP_KEEPIDLE macos equivalence

[Vincent Bernat]

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

[Vincent Bernat]

 ❦ 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: [ANNOUNCE] haproxy-2.5.2

[Vincent Bernat]

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

[Vincent Bernat]

 ❦  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: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

[Vincent Bernat]

 ❦ 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: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

[Vincent Bernat]

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

[PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

[Vincent Bernat]

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: [ANNOUNCE] haproxy-2.4.5

[Vincent Bernat]

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

Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

[Vincent Bernat]

 ❦  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] HTX vulnerability from 2.0 to 2.5-dev

[Vincent Bernat]

 ❦  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] HTTP/2 vulnerabilities from 2.0 to 2.5-dev

[Vincent Bernat]

 ❦ 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: Test, please ignore

[Vincent Bernat]

 ❦ 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] haproxy-2.3.12

[Vincent Bernat]

 ❦  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: Official ubuntu 20 repository

[Vincent Bernat]

 ❦  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=focal
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [ANNOUNCE] haproxy-2.4.0

[Vincent Bernat]

 ❦ 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: [ANNOUNCE] haproxy-2.4.0

[Vincent Bernat]

 ❦ 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: Proposal about libslz integration into haproxy

[Vincent Bernat]

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

Re: [ANNOUNCE] haproxy-2.3.9

[Vincent Bernat]

 ❦ 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: [ANNOUNCE] haproxy-2.3.9

[Vincent Bernat]

 ❦ 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: Table sticky counters decrementation problem

[Vincent Bernat]

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

[Vincent Bernat]

 ❦ 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: Packaging hatop for ubuntu20.04

[Vincent Bernat]

 ❦  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: haproxy conflict between debian backports and haproxy.debian.net

[Vincent Bernat]

 ❦ 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: haproxy conflict between debian backports and haproxy.debian.net

[Vincent Bernat]

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

[Vincent Bernat]

 ❦  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=experimental
-- 
Small things make base men proud.
-- William Shakespeare, "Henry VI"

Re: Haproxy 2.2.3 source

[Vincent Bernat]

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

[Vincent Bernat]

 ❦  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

[Vincent Bernat]

 ❦  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.2 CE issue report

[Vincent Bernat]

 ❦ 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 1.8.26-1~bpo9+1

[Vincent Bernat]

 ❦  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 1.8.26-1~bpo9+1

[Vincent Bernat]

 ❦  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

[Vincent Bernat]

 ❦  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 2.2 LTS package for Debian Stretch oldstable

[Vincent Bernat]

 ❦  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: OSX builds in Travis

[Vincent Bernat]

 ❦ 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: OSX builds in Travis

[Vincent Bernat]

 ❦ 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

[Vincent Bernat]

 ❦  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: Debian packaging note

[Vincent Bernat]

 ❦ 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: [PATCH] enable arm64 builds in travis-ci

[Vincent Bernat]

 ❦  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: Segfault on 2.1.3

[Vincent Bernat]

 ❦ 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: Segfault on 2.1.3

[Vincent Bernat]

 ❦  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

[Vincent Bernat]

 ❦  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: [PATCH] MINOR: lua: Add lua-prepend-path configuration option

[Vincent Bernat]

 ❦  9 janvier 2020 20:07 +01, Tim Düsterhus :

> If you would package the haproxy-lua-http library for Debian
> (https://github.com/haproxytech/haproxy-lua-http) [1], what would you
> believe would be most "useful" / "in spirit of Debian packaging" / "your
> choice"?
>
> a) Install the library into the regular Lua library path, even if it
> would not be useful / broken outside of HAProxy. Using require within
> HAProxy simply works without doing anything.
> b) Install the library into a HAProxy specific Lua library path (e.g.
> /usr/share/haproxy/lua-path/) and add proper lua-prepend-path to
> HAProxy's default configuration. The user would need to copy that into
> their own configuration, otherwise things break.
> c) Install the library into a HAProxy specific Lua library path and add
> that path to HAProxy at compile time via a dedicated compile option. For
> the user it would work out of the box, similar to option (a), but it
> would not clutter the global Lua library path.
> d) Something entirely different.
>
> Best regards
> Tim Düsterhus
>
> [1] I'd like to see it packaged if something useful comes out of this
> discussion :-)

Sorry for the late answer! b) doesn't seem a good solution as it
prevents sharing configuration files between distributions. I think the
default prepend path should be a compile-time option (eg
`/usr/share/haproxy/lua`) but can be overriden with a specific
directive. Therefore, this is transparent for most users, but if a user
prefer to put additional stuff in another directory, it's still easily
possible.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

Re: haproxy 2.1 package for Debian 9 Stretch oldstable

[Vincent Bernat]

 ❦ 17 décembre 2019 11:49 +01, Tim Düsterhus :

>> I didn't plan to do uploads for Stretch for this version of HAProxy.
>> This is a non-LTS version of HAProxy, so I am only targeting recent
>> distributions. If you find another people interested in this version as
>> well, I'll add it.
>
> I am interested. Due to [#931574] I am currently unable / unwilling to
> upgrade my Stretch servers to Buster. To the best of my knowledge that
> Panic still is not fixed.
>
> However I'd like to run HAProxy 2.1 on these servers.

I have pushed HAProxy 2.1.1 for Stretch. Tell me if everything is OK for
you.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Re: haproxy 2.1 package for Debian 9 Stretch oldstable

[Vincent Bernat]

 ❦ 16 décembre 2019 22:15 +01, Artur :

> While checking for haproxy 2.1 package for Debian Stretch on
> https://haproxy.debian.net/, I saw it wasn't available (yet ?).
>
> Do you plan to build haproxy deb packages for this version of Debian,
> it's still supported as oldstable for now ?

Hello,

I didn't plan to do uploads for Stretch for this version of HAProxy.
This is a non-LTS version of HAProxy, so I am only targeting recent
distributions. If you find another people interested in this version as
well, I'll add it.
-- 
It is a wise father that knows his own child.
-- William Shakespeare, "The Merchant of Venice"

Re: Status of 1.5 ?

[Vincent Bernat]

 ❦ 25 octobre 2019 11:27 +02, Willy Tarreau :

> Now I'm wondering, is anyone interested in this branch to still be
> maintained ? Should I emit a new release with a few pending fixes
> just to flush the pipe and pursue its "critical fixes only" status a
> bit further, or should we simply declare it unmaintained ? I'm fine
> with either option, it's just that I hate working for no reason, and
> this version was released a bit more than 5 years ago now, so I can
> easily expect that it has few to no user by now.
>
> Please just let me know what you think,

What's the conclusion? :)
-- 
Anyone who has had a bull by the tail knows five or six more things
than someone who hasn't.
-- Mark Twain

Re: haproxy 2.0 - stretch - libgcc_s.so.1

[Vincent Bernat]

 ❦ 27 juin 2019 09:06 +02, Mildis :

 You can workaround this by not chrooting HAProxy. The problem is that
 once chrooted, it cannot load the library. We should force libpthread to
 preload this lib.
>>> 
>>> This mailing list thread might be relevant / helpful here:
>>> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html
>>> (Message-ID: 8e3aa43f-d6ad-4128-bb10-feeb5f315...@gandi.net).
>> 
>> Thanks. Adding ADDLIB="-Wl,--no-as-needed -lgcc_s -Wl,--as-needed" fixes
>> the issue.
>
> Does 2.0.1 include the fix ?

Yes.
-- 
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)

Re: haproxy 2.0 - stretch - libgcc_s.so.1

[Vincent Bernat]

 ❦ 24 juin 2019 19:08 +02, Tim Düsterhus :

>> You can workaround this by not chrooting HAProxy. The problem is that
>> once chrooted, it cannot load the library. We should force libpthread to
>> preload this lib.
>
> This mailing list thread might be relevant / helpful here:
> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html
> (Message-ID: 8e3aa43f-d6ad-4128-bb10-feeb5f315...@gandi.net).

Thanks. Adding ADDLIB="-Wl,--no-as-needed -lgcc_s -Wl,--as-needed" fixes
the issue.

1.9 was already calling pthread_exit() but it doesn't seem to happen
with 1.9.8. Do you know what could have changed?
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"

Re: haproxy 2.0 - stretch - libgcc_s.so.1

[Vincent Bernat]

 ❦ 24 juin 2019 18:43 +02, Mildis :

> I'm hitting
> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html 
> with haproxy 2.0 on Stretch, when doing a hot-reload
>
> Jun 24 18:34:05 haproxy[32347]: libgcc_s.so.1 must be installed for 
> pthread_cancel to work
> Jun 24 18:34:05 haproxy[32347]: [WARNING] 174/183405 (32347) : Former worker 
> #1 (32363) exited with code 134 (Aborted)
>
> Is it something to be fixed by Vincent during the build for the
> packaging ?

You can workaround this by not chrooting HAProxy. The problem is that
once chrooted, it cannot load the library. We should force libpthread to
preload this lib.
-- 
The better part of valor is discretion.
-- William Shakespeare, "Henry IV"

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

[Vincent Bernat]

 ❦ 12 juin 2019 20:47 +02, Tim Duesterhus :

> - write(2, trash.area, trash.data);
> + shut_your_big_mouth_gcc(write(2, trash.area, trash.data));

An alternative not discussed in 89efaed6b67b (which introduced this
function) is to use "(void)!":

 (void)!write(2, trash.area, trash.data);

For an entertaining discussion, see:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425

Of course, like the "if (foo()) /* do nothing */;", this can be broken
in the future.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Vincent Bernat]

 ❦  8 mai 2019 13:44 +00, Veiko Kukk :

>> It was slightly modified to cleanly apply, because HAProxy's default
>> unit file does not include rsyslog.service as an 'After' dependency.
>> Also the subject line was modified to include the proper subsystem
>> and severity.
>
> I think, instead of After=rsyslog.service, it should be
> After=syslog.service, then any logger daemon could be used that has
> Alias=syslog.service.

After looking a bit more, in Debian, we are using rsyslog.service
explicitely to ensure the presence of a syslog socket inside HAProxy
chroot. As the configuration for this socket is done for rsyslog only,
we depend on rsyslog running for this aspect.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Vincent Bernat]

 ❦  8 mai 2019 16:23 +02, Tim Düsterhus :

>> I think, instead of After=rsyslog.service, it should be
>> After=syslog.service, then any logger daemon could be used that has
>> Alias=syslog.service.
>> 
>> https://www.freedesktop.org/wiki/Software/systemd/syslog/
>> 
>
> The HAProxy provided unit file does not include a dependency at all.
> That's a Debian specific patch to include the dependency.

I think we didn't know about the alias stuff. We'll fix that on our side
on next upload.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Vincent Bernat]

 ❦  6 mai 2019 13:46 +02, William Lallemand :

>> /etc/default is a debianism. Other distros use different directories, 
>> such as RedHat which uses /etc/sysconfig
>> 
>> -Patrick
>
> Hi Patrick,
>
> I don't think that's a problem, most distribution use their own unit file
> anyway, people should edit this file before using it.

One of the promise of systemd was to be able to share unit files accross
distribution. For this, systemd wants to discourage the use of
/etc/default and /etc/sysconfig (there was even a discussion about
deprecating EnvironmentFile). You can still use the EXTRAOPTS approach
by using:

ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG $EXTRAOPTS

And let people override EXTRAOPTS with an override:

Environment=EXTRAOPTS=somethingmore

However, many people prefer /etc/default and /etc/sysconfig to systemd
overrides. And for distribution, it enables a smoother transition. For
Debian, we would still add the EnvironmentFile directive. You could
still be compatible with both styles of distribution with:

EnvironmentFile=-/etc/default/haproxy
EnvironmentFile=-/etc/sysconfig/haproxy
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: [ANNOUNCE] haproxy-1.8.20

[Vincent Bernat]

 ❦  5 mai 2019 09:51 +02, Vincent Bernat :

>> So I'd suggest to insist on having the up to date version (even 1.8.21 if
>> we have a reason to have this one released by then). In the worst case,
>> if this is rejected for whatever reason, it's better to leave a 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!

They don't want to make an exception. So, Debian 10 will be with HAProxy
1.8.19.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [ANNOUNCE] haproxy-1.8.20

[Vincent Bernat]

 ❦  5 mai 2019 09:14 +02, Willy Tarreau :

> So I'd suggest to insist on having the up to date version (even 1.8.21 if
> we have a reason to have this one released by then). In the worst case,
> if this is rejected for whatever reason, it's better to leave a well known
> version there and continue 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)

Re: [ANNOUNCE] haproxy-1.8.20

[Vincent Bernat]

 ❦ 29 avril 2019 11:04 +02, Christopher Faulet :

> HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits
> after version 1.8.19.

Hey!

Debian Buster will soon be released (nobody knows exactly when, but we
are in full freeze since 2 months). It currently contains HAProxy
1.8.19. I 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: haproxy segfault

[Vincent Bernat]

 ❦ 12 février 2019 21:44 +01, Mildis :

> I'm struggling with Stretch/systemd to generate the coredump on crash.
> Even running haproxy by hand with ulimit -c unlimited does not
> generate a coredump.

Also install haproxy-dbgsym. You need to comment the chroot directive in
your HAProxy 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: DNS resolution issue with Docker swarm and HAProxy 1.8.15/1.9.0

[Vincent Bernat]

 ❦ 20 décembre 2018 17:14 +01, Willy Tarreau :

>> this is indeed a regression in haproxy.  thanks for reporting it.
>> attached patch should fix it.
>> CC'ing Remi as the original author, and Baptiste, as DNS maintainer.
>
> Good catch, the patch looks obviously good, I've just merged it.
> 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: [ANNOUNCE] haproxy-1.8.13

[Vincent Bernat]

 ❦ 30 juillet 2018 20:55 +0200, Willy Tarreau  :

> What I don't like with PGP on an exposed machine is that it reduces the
> size of your 4096-bit key to the size of your passphrase (which most
> often contains much less than the ~700 characters it would need to be
> as large), and also increases your ability to get fooled into entering
> it. Some would call me paranoid, but I don't think I am, I'm just trying
> to keep a balanced level of security, knowing that the global one is not
> better than the weakest point.

Attacks on asymmetric ciphers do not rely on bruteforce: you don't have
to explore the whole keyspace to guess the private key. You can use
algorithms like the general number field sieve. A 4096-bit RSA keypair
would be roughly equivalent to a symmetric algorithm using a 160-bit key
(unless we find better algorithms to break RSA). A 32-character
passphrase would be enough to protect the private key. Moreover, if you
use a weaker passphrase, you have not lost yet as the string to key
function used to turn the passphrase into an AES key is slow. I don't
know where the limit is, but the idea is that with a shorter passphrase,
the attacker may still have a better time finding the AES key instead of
the passphrase.

But if someone can steal your encrypted key from your machine, they may
also be able to steal the unencrypted one through various means. So, you
may still be right about being paranoid. :)
-- 
The man who sets out to carry a cat by its tail learns something that
will always be useful and which never will grow dim or doubtful.
-- Mark Twain

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

[Vincent Bernat]

 ❦ 12 juillet 2018 16:25 +0200, William Lallemand  :

> Maybe we could take your first patch for the unit file and backport it in 1.8,
> and then make the appropriate changes for 1.9 once the master was
> redesigned.

Yes, no problem. The first patch should apply without any change on 1.8.
I am using it in Debian packages and so far, nobody complained.
-- 
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

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

[Vincent Bernat]

 ❦ 22 juin 2018 22:03 +0200, Vincent Bernat  :

> Without this patch, when killing the master process, the SIGTERM
> signal is forwarded to all children. Last children will likely exit
> with "killed by signal SIGTERM" status which would be converted by an
> exit with status 143 of the master process.
>
> With this patch, the master process takes note it is requesting its
> children to stop and will convert "killed by signal SIGTERM" to an
> exit status of 0. Therefore, the master process will exit with status
> 0 if everything happens as expected.

I think this patch may have slipped through the cracks!
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain

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

[Vincent Bernat]

 ❦ 22 juin 2018 22:03 +0200, Vincent Bernat  :

>   if (current_child(exitpid)) {
>   ha_alert("Current worker %d exited with code 
> %d\n", exitpid, status);

This is a lie, but I don't think it matters much. We could (mentally)
translate "with code 0" by "with success".
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Vincent Bernat]

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

With this patch, the master process takes note it is requesting its
children to stop and will convert "killed by signal SIGTERM" to an
exit status of 0. Therefore, the master process will exit with status
0 if everything happens as expected.

Killing a worker process with SIGTERM will still trigger an exit of
the master process with a status of 143.
---
 src/haproxy.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 11d1d47ceb41..2f11ad124873 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -723,6 +723,7 @@ static void mworker_wait()
 {
int exitpid = -1;
int status = 0;
+   int exiting = 0;
 
 restart_wait:
 
@@ -749,6 +750,7 @@ restart_wait:
}
 #endif
ha_warning("Exiting Master process...\n");
+   exiting = 1;
mworker_kill(sig);
mworker_unregister_signals();
}
@@ -763,8 +765,13 @@ restart_wait:
 
if (WIFEXITED(status))
status = WEXITSTATUS(status);
-   else if (WIFSIGNALED(status))
-   status = 128 + WTERMSIG(status);
+   else if (WIFSIGNALED(status)) {
+   if (exiting && (WTERMSIG(status) == SIGINT ||
+   WTERMSIG(status) == SIGTERM))
+   status = 0;
+   else
+   status = 128 + WTERMSIG(status);
+   }
else if (WIFSTOPPED(status))
status = 128 + WSTOPSIG(status);
else
@@ -776,7 +783,7 @@ restart_wait:
/* check if exited child was in the current children 
list */
if (current_child(exitpid)) {
ha_alert("Current worker %d exited with code 
%d\n", exitpid, status);
-   if (status != 0 && status != 130 && status != 
143
+   if (status != 0
&& !(global.tune.options & 
GTUNE_NOEXIT_ONFAILURE)) {
ha_alert("exit-on-failure: killing 
every workers with SIGTERM\n");
mworker_kill(SIGTERM);
-- 
2.18.0

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

[Vincent Bernat]

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

This has mostly a cosmetic effect. Without the patch, stopping HAProxy
leads to the following status:

● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-06-22 20:35:42 CEST; 
8min ago
 Docs: man:haproxy(1)
   file:/usr/share/doc/haproxy/configuration.txt.gz
  Process: 32715 ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE 
$EXTRAOPTS (code=exited, status=143)
  Process: 32714 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS 
(code=exited, status=0/SUCCESS)
 Main PID: 32715 (code=exited, status=143)

After the patch:

● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:haproxy(1)
   file:/usr/share/doc/haproxy/configuration.txt.gz
---
 contrib/systemd/haproxy.service.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/systemd/haproxy.service.in 
b/contrib/systemd/haproxy.service.in
index 7a8b6bead2df..74e66e302065 100644
--- a/contrib/systemd/haproxy.service.in
+++ b/contrib/systemd/haproxy.service.in
@@ -10,6 +10,7 @@ ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q
 ExecReload=/bin/kill -USR2 $MAINPID
 KillMode=mixed
 Restart=always
+SuccessExitStatus=143
 Type=notify
 
 # The following lines leverage SystemD's sandboxing options to provide
-- 
2.18.0

Re: Haproxy 1.7.10 constantly restarting

[Vincent Bernat]

 ❦ 11 mars 2018 07:19 -0400, Aleksey Gordeev  :

> I'm sorry is that question is not suitable. Please give correct channel to 
> contact. 
>
> It's started about a month ago. I have separate instances of same
> version haproxy. One of them restarts every 2 or 3 days.
>
> I have only this in log 
>
> Mar 11 06:43:21  systemd[1]: Stopping HAProxy Load Balancer... 
> Mar 11 06:43:21  haproxy-systemd-wrapper[10939]: haproxy-systemd-wrapper: 
> SIGTERM -> 10942. 
> Mar 11 06:43:21  haproxy-systemd-wrapper[10939]: haproxy-systemd-wrapper: 
> exit, haproxy RC=0 
> Mar 11 06:43:21  systemd[1]: Starting HAProxy Load Balancer... 
> Mar 11 06:43:21  systemd[1]: Started HAProxy Load Balancer. 
> Mar 11 06:43:21  haproxy-systemd-wrapper[19642]: haproxy-systemd-wrapper: 
> executing /usr/sbin/haproxy 

This seems to happen because something is just restarting haproxy. Maybe
logrotate? "rgrep haproxy /etc" may give a clue.
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Syslog with systemd

[Vincent Bernat]

 ❦  2 mars 2018 19:24 +1100, Igor Cicimov  :

>> I suppose the permissions of /var/log are incorrect. It should be owned
>> by syslog?
>
> ​The permissions look ok:
> ​
> ​# ls -ld /var/log/
> drwxrwxr-x 16 root syslog 4096 Mar  2 00:00 /var/log/
> # id -a syslog
> uid=104(syslog) gid=108(syslog) groups=108(syslog),4(adm)​

I don't use rsyslog myself, so I can't help you more.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Syslog with systemd

[Vincent Bernat]

 ❦  2 mars 2018 09:49 +1100, Igor Cicimov  :

> $ ls -l /var/log/haproxy.log
> -rw-r- 1 syslog adm 48939 Mar  1 20:17 /var/log/haproxy.log
>
> ​and I'm sure this file was automatically created ​(by rsyslog I guess?).
> I'm sure this has always been the case hence the reason I was confused when
> I had to create it manually (obviously with wrong permissiosn :-/ ).
>
> So the question is now why this file did not get created in the first place
> although I restarted rsyslog and haproxy several times?

I suppose the permissions of /var/log are incorrect. It should be owned
by syslog?
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Syslog with systemd

[Vincent Bernat]

 ❦ 28 février 2018 22:14 +1100, Igor Cicimov  :

> ​Same, no logging:​
[...]

Could you strace rsyslogd and check if it is receiving the messages?
-- 
This is the first age that's paid much attention to the future, which is a
little ironic since we may not have one.
-- Arthur Clarke

Re: Syslog with systemd

[Vincent Bernat]

 ❦ 28 février 2018 21:00 +1100, Igor Cicimov  :

> ​# ls -l /var/lib/haproxy/dev/log
> srw-rw-rw- 1 root root 0 Feb 28 16:06 /var/lib/haproxy/dev/log
>
> # lsof -n -p $(pidof haproxy) | grep dev/log
> #

In fact, this seems expected because HAProxy is only using
non-connection oriented sockets.

If you run HAProxy outside of systemd, does it work as expected? If yes,
what's the output of (when running through systemd):

cat /proc/$(pidof haproxy)/mounts
-- 
Why is it that we rejoice at a birth and grieve at a funeral?  It is because we
are not the person involved.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: Syslog with systemd

[Vincent Bernat]

 ❦ 28 février 2018 17:51 +1100, Igor Cicimov  :

>> > ​Actually spoke too soon, still have an issue. One of the servers started
>> > logging there but then stopped and on the other the file is still empty.​
>>
>> Is the issue fixed just by restarting HAProxy or does it persist after
>> that?
>
> ​No restart didn't help still same.​

Those commands should help understand the situation better (you may have
to adapt them if pidof returns several PID).

ls -l /var/lib/haproxy/dev/log
lsof -n -p $(pidof haproxy) | grep dev/log
lsof -n -p $(pidof rsyslogd) | grep haproxy/dev/log
-- 
The surest protection against temptation is cowardice.
-- Mark Twain

Re: Syslog with systemd

[Vincent Bernat]

 ❦ 28 février 2018 15:50 +1100, Igor Cicimov  :

> ​Actually spoke too soon, still have an issue. One of the servers started
> logging there but then stopped and on the other the file is still empty.​

Is the issue fixed just by restarting HAProxy or does it persist after that?
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

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

[Vincent Bernat]

 ❦ 27 février 2018 16:00 +0100, Willy Tarreau  :

>> I'm running this exact settings on my Debian Stretch machine using haproxy
>> 1.8.x, without issues so far.
>> 
>> The first patch could cause issues for users that store their configuration
>> in /home or /root, but I consider this unlikely.
>> 
>> Tim Duesterhus (2):
>>   MINOR: systemd: Add SystemD's Protect*= options to the unit file
>>   MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file
>
> I took a look, but my systemd incompetence limited my ability to understand
> what this really does. How does systemd act to do this exactly ? I'm very
> worried that the only way it could proceed would be by running the process
> under ptrace causing a tremendous slowdown, and additionally making the
> process unobservable/undebuggable. Do you know how it proceeds
> internally ?

It uses seccomp.
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)

Re: HTTP/2 Termination vs. Firefox Quantum

[Vincent Bernat]

 ❦ 21 décembre 2017 09:00 GMT, Maximilian Böhm  :

> We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the 
> backend, jetty 9.3.11.v20160721 with http/1.1 answers requests.
>
> Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues with 
> Firefox Quantum both, on windows 10 and macOS. I do not have any complaints 
> regarding other browsers (yet?). Requested HTML pages are delivered empty or 
> even cut in the middle. There is no recurring pattern, it's like a lottery, 
> still, very seldom.. The yet simple but not satisfiable solution is to 
> restart the browser.
>
> I know the provided information is quite spare, so my question is
> actually, if there Is there any guideline I can follow to provide you
> more information? I've appended some snippets of the proxy
> configuration.

Also provide "haproxy -vv". I believe in your case, this is:

HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 
USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.2l  25 May 2017
Running on OpenSSL version : OpenSSL 1.0.2l  25 May 2017
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 PCRE version : 8.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE 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
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)

[PATCH] MINOR: systemd: remove comment about HAPROXY_STATS_SOCKET

[Vincent Bernat]

From: Vincent Bernat <vinc...@bernat.im>

This variable was used by the wrapper which was removed in
a6cfa9098e5a. The correct way to do seamless reload is now to enable
"expose-fd listeners" on the stat socket.
---
 contrib/systemd/haproxy.service.in | 2 --
 1 file changed, 2 deletions(-)

diff --git a/contrib/systemd/haproxy.service.in 
b/contrib/systemd/haproxy.service.in
index edbd4c292dd5..804be3583c1a 100644
--- a/contrib/systemd/haproxy.service.in
+++ b/contrib/systemd/haproxy.service.in
@@ -3,8 +3,6 @@ Description=HAProxy Load Balancer
 After=network.target
 
 [Service]
-# You can point the environment variable HAPROXY_STATS_SOCKET to a stats
-# socket if you want seamless reloads.
 Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
 ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q
 ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE
-- 
2.15.1

Re: HTTP/2 stream 1 was not closed cleanly

[Vincent Bernat]

 ❦  4 décembre 2017 12:34 GMT, Gregory Storme  :

> haproxy -vv
> HA-Proxy version 1.8.0-2~bpo8+1 2017/12/02

If you want to try with 1.8.1, it has just been uploaded.
-- 
Lord, what fools these mortals be!
-- William Shakespeare, "A Midsummer-Night's Dream"

Re: Client cert verification on some paths

[Vincent Bernat]

 ❦  2 décembre 2017 10:47 GMT, "Aleksandar Lazic"  :

> You can use the following line to full fill your request, untested.
>
>   bind :443 ssl ca-file "${PATH_TO_CAFILE}" crl-file
> "${PATH_TO_CRLFILE}" verify "${VERIFY_MODE}"

If verify mode is set to optional, on browsers, 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: patch: allow to use any compiler

[Vincent Bernat]

 ❦  9 octobre 2017 08:49 +0500, Илья Шипицин  :

>> > any particular reason for mixing "CC=gcc" with "CC?=gcc" ?
>>
>> I don't see any use of ?=, except for stuff that are expected to be in
>> environment variables (like HOME, DISPLAY, LANG, PATH).
>>
>
> # find . -name 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: patch: allow to use any compiler

[Vincent Bernat]

 ❦  8 octobre 2017 15:46 +0500, Илья Шипицин  :

>> > while some Makefiles allow to use CC, other just stick to gcc.
>> > I think we should change to
>> >
>> > CC ?= gcc
>>
>> This doesn't change much. You can already override gcc with "make
>> TARGET=... CC=clang". The only 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

[Vincent Bernat]

 ❦  4 octobre 2017 23:49 +0500, Илья Шипицин  :

> while some Makefiles allow to use CC, other just stick to gcc.
> I think we should change to
>
> CC ?= gcc

This doesn't change much. You can already override gcc with "make
TARGET=... CC=clang". The only thing "?=" is that 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: Haproxy segfault error 4 in libc-2.24

[Vincent Bernat]

 ❦  3 octobre 2017 17:54 +0200, Marcus Ulbrich  :

> yes... it crashed after 5mins also without this acl.

I was suspecting this ACL as this is the only one with a
case-insensitive match. But maybe the same codepath is used when
matching header names.

> I should test 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)