[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check
If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.
This patch should fix the issue #1176. It must be backported as far as 2.2.
(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
Vincent Bernat [Mon, 30 Nov 2020 19:02:49 +0000 (19:02 +0000)]
haproxy (2.2.6-1) unstable; urgency=medium
* New upstream release.
- BUG/MAJOR: filters: Always keep all offsets up to date during data
filtering
- BUG/MAJOR: peers: fix partial message decoding
- BUG/MAJOR: spoe: Be sure to remove all references on a released spoe
applet
- BUG/MAJOR: tcpcheck: Allocate input and output buffers from the buffer
pool
* d/patches: remove patches applied upstream
[PATCH 2/2] BUG/MINOR: http-htx: Just warn if payload of an errorfile doesn't match the C-L
During startup, when an errorfile is parsed, if its payload does not match the
announced content-length, an error is triggered. This change was introduced in
the 2.3, which is ok. But for a stable release it may be seen as a
regression. Thus, now a warning is emitted, instead of an error. And the
content-length header is updated with the real payload length.
This patch depends on 58f55acf4e ("MINOR: http-htx: Add understandable errors
for the errorfiles parsing"). Both must be backported as far as 2.0. This bug
only exists in the 2.2, 2.1 and 2.0. Thus, there is no upstream commit ID for
this patch.
Gbp-Pq: Name 0002-BUG-MINOR-http-htx-Just-warn-if-payload-of-an-errorf.patch
[PATCH 1/2] MINOR: http-htx: Add understandable errors for the errorfiles parsing
No details are provided when an error occurs during the parsing of an errorfile,
Thus it is a bit hard to diagnose where the problem is. Now, when it happens, an
understandable error message is reported.
This patch is not a bug fix in itself. But it will be required to change an
fatal error into a warning in last stable releases. Thus it must be backported
as far as 2.0.
(cherry picked from commit a66adf41ea28a0fa29437d1675f225b5cc589b59) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3a10710b777370ef36763b8b6658ae63ef5c4ec4) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-MINOR-http-htx-Add-understandable-errors-for-the-err.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01
Gbp-Pq: Name haproxy.service-start-after-syslog.patch
projects / haproxy.git / log