Re: [ANNOUNCE] haproxy-2.0.16
Christopher, Am 17.07.20 um 17:19 schrieb Christopher Faulet: > Le 17/07/2020 à 16:58, Tim Düsterhus a écrit : >> Christopher, >> >> Am 17.07.20 um 16:34 schrieb Christopher Faulet: >>> HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits >>> after version >>> 2.0.15. >> >> I'm a bit surprised seeing a new 2.0 before a new 2.1 / 2.2. Will they >> also come today? I'm especially interested in 2.1.8 because of this >> patch: >> http://git.haproxy.org/?p=haproxy-2.1.git;a=commit;h=4cbc30d405b06e7ff1ba6a6f3be58af786af81bc >> >> >> While I deployed a custom built 2.2 today for #758 I don't want to do >> this on all machines due to the increased operational effort. >> >> Also releasing a new 2.0 before the newer branches violates the contract >> that upgrading HAProxy to a newer branch will never reintroduce fixed >> bugs. I believe I read this contract somewhere in the past, but I can't >> find it right now. >> > > I released the 2.0.16 in first because of a major bug on the 2.0.15 > about random backend connections on connection retry. So, I guess we may Yes, I understand that 2.0.16 was a very important release for users of 2.0.x. > emit a 2.1 too. There are some annoying medium bugs and the 2.1.7 is 1.5 > month old. For the 2.2, there are still pending bugs we should fix > before emitting a new release. At least the issue #758 as you said, but > also the #756. > I found the "contract" I was referring to: https://github.com/haproxy/haproxy/blob/a267b5df4a20016a7daee5f457b219c1a2c48f39/BRANCHES#L98-L108 I quote, highlighting mine: > The fix will be backported into 1.9 and from there into 1.8. 1.9.5 **will be issued with the fix before** 1.8.19 will be issued. This guarantees that for any version 1.8 having the fix, there always exists a version 1.9 with it as well. I understand that releasing a new version takes time to write the announcement and stuff and I also understand that 2.0 had priority. But I don't think that excuses violating one's own rules that exist for good reason. Users upgrading from 2.0.16 to 2.2.0 will now see bugs that have already been fixed in 2.0.16, but not 2.2.0. Best regards Tim Düsterhus
Re: [ANNOUNCE] haproxy-2.0.16
Hi Dmitry
On Sat, Jul 18, 2020 at 12:29:10PM +0300, Dmitry Sivachenko wrote:
>
> 1) new warnings:
>
> src/log.c:1692:10: warning: logical not is only applied to the left hand side
> of this comparison [-Wlogical-not-parentheses]
> while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
>^ ~~
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
> src/log.c:1692:10: note: add parentheses after the '!' to evaluate the
> comparison first
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
> src/log.c:1692:10: note: add parentheses around left hand side expression to
> silence this warning
> while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
>^
>( )
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
>
This looks like a missing backport because the issue was encountered and
fixed in master.
https://github.com/haproxy/haproxy/commit/db57a142c31016ff3e0dd533cb2b4de14445781e
--
Jérôme
Re: [ANNOUNCE] haproxy-2.0.16
> On 18 Jul 2020, at 12:40, Илья Шипицин wrote: > > What is freebsd version? > It was 13.0-CURRENT, but after you asked I also tried 12.1-STABLE (clang version is also 10.0.0): the same warnings/error.
Re: [ANNOUNCE] haproxy-2.0.16
What is freebsd version?
On Sat, Jul 18, 2020, 2:32 PM Dmitry Sivachenko wrote:
>
>
> > On 17 Jul 2020, at 17:34, Christopher Faulet
> wrote:
> >
> >
> > Hi,
> >
> > HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits after
> version
> > 2.0.15.
>
> Hello,
>
> Here are new compile problems since 2.0.14 (FreeBSD/amd64, clang version
> 10.0.0)
>
> 1) new warnings:
>
> src/log.c:1692:10: warning: logical not is only applied to the left hand
> side of this comparison [-Wlogical-not-parentheses]
> while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
>^ ~~
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
> src/log.c:1692:10: note: add parentheses after the '!' to evaluate the
> comparison first
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
> src/log.c:1692:10: note: add parentheses around left hand side expression
> to silence this warning
> while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
>^
>( )
> include/common/hathreads.h:1026:33: note: expanded from macro
> 'HA_SPIN_TRYLOCK'
> #define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
> ^
>
>
> 2) compile error (can be fixed by including
>
> ebtree/ebtree.c:43:2: error: use of undeclared identifier 'ssize_t'; did
> you mean 'sizeof'?
> ssize_t ofs = -len;
> ^~~
> sizeof
> ebtree/ebtree.c:43:10: error: use of undeclared identifier 'ofs'
> ssize_t ofs = -len;
> ^
> ebtree/ebtree.c:47:13: error: use of undeclared identifier 'ofs'
> diff = p1[ofs] - p2[ofs];
> ^
> ebtree/ebtree.c:47:23: error: use of undeclared identifier 'ofs'
> diff = p1[ofs] - p2[ofs];
> ^
> ebtree/ebtree.c:48:22: error: use of undeclared identifier 'ofs'
> } while (!diff && ++ofs);
>
>
>
Re: [ANNOUNCE] haproxy-2.0.16
> On 17 Jul 2020, at 17:34, Christopher Faulet wrote:
>
>
> Hi,
>
> HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits after
> version
> 2.0.15.
Hello,
Here are new compile problems since 2.0.14 (FreeBSD/amd64, clang version 10.0.0)
1) new warnings:
src/log.c:1692:10: warning: logical not is only applied to the left hand side
of this comparison [-Wlogical-not-parentheses]
while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
^ ~~
include/common/hathreads.h:1026:33: note: expanded from macro 'HA_SPIN_TRYLOCK'
#define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
^
src/log.c:1692:10: note: add parentheses after the '!' to evaluate the
comparison first
include/common/hathreads.h:1026:33: note: expanded from macro 'HA_SPIN_TRYLOCK'
#define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
^
src/log.c:1692:10: note: add parentheses around left hand side expression to
silence this warning
while (HA_SPIN_TRYLOCK(LOGSRV_LOCK, &logsrv->lock) != 0) {
^
( )
include/common/hathreads.h:1026:33: note: expanded from macro 'HA_SPIN_TRYLOCK'
#define HA_SPIN_TRYLOCK(lbl, l) !pl_try_s(l)
^
2) compile error (can be fixed by including
ebtree/ebtree.c:43:2: error: use of undeclared identifier 'ssize_t'; did you
mean 'sizeof'?
ssize_t ofs = -len;
^~~
sizeof
ebtree/ebtree.c:43:10: error: use of undeclared identifier 'ofs'
ssize_t ofs = -len;
^
ebtree/ebtree.c:47:13: error: use of undeclared identifier 'ofs'
diff = p1[ofs] - p2[ofs];
^
ebtree/ebtree.c:47:23: error: use of undeclared identifier 'ofs'
diff = p1[ofs] - p2[ofs];
^
ebtree/ebtree.c:48:22: error: use of undeclared identifier 'ofs'
} while (!diff && ++ofs);
Re: [ANNOUNCE] haproxy-2.0.16
Le 17/07/2020 à 16:58, Tim Düsterhus a écrit : Christopher, Am 17.07.20 um 16:34 schrieb Christopher Faulet: HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits after version 2.0.15. I'm a bit surprised seeing a new 2.0 before a new 2.1 / 2.2. Will they also come today? I'm especially interested in 2.1.8 because of this patch: http://git.haproxy.org/?p=haproxy-2.1.git;a=commit;h=4cbc30d405b06e7ff1ba6a6f3be58af786af81bc While I deployed a custom built 2.2 today for #758 I don't want to do this on all machines due to the increased operational effort. Also releasing a new 2.0 before the newer branches violates the contract that upgrading HAProxy to a newer branch will never reintroduce fixed bugs. I believe I read this contract somewhere in the past, but I can't find it right now. I released the 2.0.16 in first because of a major bug on the 2.0.15 about random backend connections on connection retry. So, I guess we may emit a 2.1 too. There are some annoying medium bugs and the 2.1.7 is 1.5 month old. For the 2.2, there are still pending bugs we should fix before emitting a new release. At least the issue #758 as you said, but also the #756. -- Christopher Faulet
Re: [ANNOUNCE] haproxy-2.0.16
Christopher, Am 17.07.20 um 16:34 schrieb Christopher Faulet: > HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits after > version > 2.0.15. I'm a bit surprised seeing a new 2.0 before a new 2.1 / 2.2. Will they also come today? I'm especially interested in 2.1.8 because of this patch: http://git.haproxy.org/?p=haproxy-2.1.git;a=commit;h=4cbc30d405b06e7ff1ba6a6f3be58af786af81bc While I deployed a custom built 2.2 today for #758 I don't want to do this on all machines due to the increased operational effort. Also releasing a new 2.0 before the newer branches violates the contract that upgrading HAProxy to a newer branch will never reintroduce fixed bugs. I believe I read this contract somewhere in the past, but I can't find it right now. Best regards Tim Düsterhus
[ANNOUNCE] haproxy-2.0.16
Hi, HAProxy 2.0.16 was released on 2020/07/17. It added 45 new commits after version 2.0.15. A major issue was fixed when a connection retry is performed after a failure. In this case, a new connection was created but the destination address was not set again. So, if the connection was recycled from the memory pool, the previous address was used, leading to a connection established to a random destination (to any server in any backend). If a freshly allocated connection was used, no destination address was set, leading to an internal error. The bug comes from a recent fix to avoid some crashes when using L7 retries. Only the 2.0.15 is affected by this bug. Many thanks to Michael Wimmesberger for its detailed bug report and its reproducer. This bug reveals another one about connection retries when the plain HTTP proxy mode is used (http_proxy option). On the 2.0.15, it does not work anymore because, on failure, the connection is released and, with it, all information about the destination address it carried. Because there was no simple solution to fix this bug and because it is not a so commonly used option, we decided to simply disable the connection retries in this case. This limitation is specific to the 2.0. Some issues about the splicing for HTTP/1 sessions were fixed. A freeze of the connection may be experienced if a shutdown for reads is received while the splicing is in use. Another freeze may also be experienced if more than tune.recv_enough bytes are moved to a pipe and immediately sent. It happens because the FD's ability to read is not re-enabled after a successful send on the opposite side. To fix the bug, the FD's ability to read is no more checked when we try to move data to a pipe. At worst, we have an extra syscall from time to time. Next, a wakeups loop on an HTTP/1 connection was fixed. It may happen if the splicing is in use with no data in the pipe. Finally, the splicing now works again for connections in tunnel mode. A bug leading to a wakeups loop of the LUA cosocket's applet was fixed. It is due to an old bug in the way data are read on LUA cosocket, especially if the read per line is used. An unfinished line is never consumed, even if a shutdown for writes is pending. The applet is woken up in loop to flush the data to ack the shutdown for writes but data are never consumed. And, as usual, a bunch of fixes or minor changes here and there. Among others : - An old issue about the watchdog triggering when reloading huge maps was fixed. - The hdr_ip sample fetch function was fixed. It could parse more characters than really present in the sample, occasionally causing some trailing digits present in a previous sample to be read. - Pattern matching against strings was fixed to be sure to always add a trailing null character to the tested string. If the buffer is not large enough, it is now duplicated. This fixes a possible buffer overflow. - The command line finally supports escaping spaces using a backslash, thanks to Yves Lafon, and to William who could adjust the master CLI code to match it. - "show sess" would endlessly dump new streams when they arrive too fast. It was a real pain so now it will only dump past the last stream known at the moment the command is typed. This means that it may show less streams than the total, but will not result in multi-gigabyte dumps anymore. - New set of ssl_s_* sample fetch functions to retrieve information about a server's SSL certificate. - For systemd users, the network dependency to start haproxy in the unit file was fixed, thanks to a patch from Ryan O'Hara. It will now wait for an online network. This is so that those who use DNS names where addresses are expected don't have startup failures at boot. - 404, 410 and 413 status codes are now supported in errorfiles. Don't forget to update to this version if you are using the 2.0 branch, especially if you are running the 2.0.15. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/2.0/src/ Git repository : http://git.haproxy.org/git/haproxy-2.0.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.0.git Changelog: http://www.haproxy.org/download/2.0/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ --- Complete changelog : Anthonin Bonnefoy (1): MINOR: http: Add support for http 413 status Christopher Faulet (14): REGTEST: Add a simple script to tests errorfile directives in proxy sections MINOR: spoe: Don't systematically create new applets if processing rate is low BUG/MEDIUM: pattern: Add a trailing \0 to match strings only if possible BUG/MINOR: mux-h1: F
