Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 11674 articles
Browse latest View live
↧

Re: Grrrr.... warnings

April 2, 2018, 8:00 am
$
0
0
You can rewrite haproxy with Lua. It was announced one year and one
day ago. It’s time ... :-)

Thierry

-

> On 1 Apr 2018, at 23:24, Willy Tarreau <w@1wt.eu> wrote:
>
> Can someone tell me how I'm supposed to work around this one ?
>
> gcc -Iinclude -Iebtree -Wall -O2 -march=native -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-unused-label -DBUFSIZE=8030 -DMAXREWRITE=1030 -DSO_MARK=36 -DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT -DUSE_ZLIB -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_THREAD -DUSE_OPENSSL -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\"1.9-dev0-495298-299\" -DCONFIG_HAPROXY_DATE=\"2018/03/21\" \
> -DBUILD_TARGET='"linux2628"' \
> -DBUILD_ARCH='""' \
> -DBUILD_CPU='"native"' \
> -DBUILD_CC='"gcc"' \
> -DBUILD_CFLAGS='"-O2 -march=native -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-unused-label -DBUFSIZE=8030 -DMAXREWRITE=1030 -DSO_MARK=36"' \
> -DBUILD_OPTIONS='"USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1"' \
> -c -o src/haproxy.o src/haproxy.c
>
> src/haproxy.c:1:1: warning: gcc has detected the presence of C code in this file. This language is potentially unsafe as it lets the developer do things that the compiler doesn't understand. Please upgrade to a new language, support will be deprecated in gcc-9. [-Wc-deprecated].
>
> Thanks,
> Willy
>
↧
Search

Re: Why maxconn value can have a negative value?

April 2, 2018, 8:10 am
$
0
0
Willy,

Am 02.04.2018 um 16:46 schrieb Willy Tarreau:
> Very likely not, I think that maxconn is 0 when not set, so most likely
> it's a leftover from old code.
>

I don't feel confident touching these members (there's also a few more
which probably should be unified). If you decide to take a look at it
also take a look at `struct listener`, which also contains a `maxconn`
member.

Best regards
Tim Düsterhus
↧
↧

resolvers - resolv.conf fallback

April 2, 2018, 8:20 am
$
0
0
Assuming no one else is already working on the feature, I'd like to
contribute
the change to have the resolvers section fall back to parsing
/etc/resolv.conf
when no nameserver directives are present.

This was previously discussed here: https://www.mail-
archive.com/haproxy@formilux.org/msg28626.html.
(Jim Freeman and I are colleagues.)

I've been surveying the code to see how it could be implemented. I think it
would make sense to register a 'post_section_parser' for the resolvers
section
that would add the nameservers from /etc/resolv.conf if no nameservers were
specified in the section. As Jim pointed out previously, libresolv could be
used
to parse the file. If that's undesirable for some reason, we could parse it
ourselves.

I'm new to the codebase, so I'm open to any suggestions or guidance anyone
may have.

Thanks,

Ben
↧

Re: Segmentation faults (1.8.4-de425f6 2018/02/26)

April 2, 2018, 4:40 pm
$
0
0
Hi Willy,

alright, I updated to latest snapshot.
Thanks for all your work!
↧

DNS resolver and mixed case responses

April 3, 2018, 7:30 am
$
0
0
Hello All,

I have noticed a potential issue in HAProxy 1.7 where a backend server has
reported in logs an 'unspecified DNS error' and been marked down for
maintenance.

After some investigation, I have found that our internal DNS server is
responding with non-lowercase domain names in the Answer section. When
HAProxy 'check' performs the lookup in dns.c the validation on the Answer
domain with memcmp fails.

I'm trying to understand what system is at fault here; the DNS server for
not responding with the same case as the query, or HAProxy which should be
performing a case insensitive match.
I have made some test changes to src/dns.c to implement case insensitive
matching in line 260 (in dns_resolve_recv) and unifying case before
returning in dns_read_name. After these changes I can no longer reproduce
the problem. I'm happy to share my patch file, but expect that your own
libs and implementation will be cleaner.
Relevant RFC: https://tools.ietf.org/html/rfc4343#section-3

The current viable workaround appears to be simply matching the case that
the DNS server is configured to reply with. For us this means specifying
something like 'Server.db.example.com' instead of 'server.db.example.com'
in haproxy.cfg.


Reproduction steps:
* Use 'check' and 'resolvers' in server section to enable
post-initialisation dns lookups.
* Have the DNS resolver reply in upper/lower/mixed case that does not match
config file. (I can share a small python script that can be used to test
this)
The initial resolution during config read is fine, as this is done via
libc. The subsequent DNS resolutions during checks fail and eventually set
the server as offline.

---
Sample configuration to reproduce:
defaults
log global
mode tcp
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s

resolvers dns-resolver
nameserver ns1 127.0.0.1:1153
resolve_retries 3
timeout retry 1s
hold valid 2s # small, so we can reproduce quickly
hold other 10s

frontend fe15000
bind :15000
default_backend be15000

backend be15000
server dest15000 example.com:5000 check resolvers dns-resolver
init-addr libc,none
---

Sample DNS response that triggers the issue:
(Note the reply CaSe does not match query. I can also provide a simple
Python server that performs uppercase in its reply, for replication of
this.)
---
$ dig @127.0.0.1 -p 1153 example.com
<snip>
;; QUESTION SECTION:
;EXAMPLE.COM. IN A

;; ANSWER SECTION:
EXAMPLE.COM. 60 IN A 127.0.0.1
<snip>


Thanks for any assistance,
Dale Smith
↧
↧

Re: DNS resolver and mixed case responses

April 3, 2018, 9:40 am
$
0
0
On Tue, Apr 3, 2018 at 4:17 PM, Dale Smith <dalees@gmail.com> wrote:

> Hello All,
>
> I have noticed a potential issue in HAProxy 1.7 where a backend server has
> reported in logs an 'unspecified DNS error' and been marked down for
> maintenance.
>
> After some investigation, I have found that our internal DNS server is
> responding with non-lowercase domain names in the Answer section. When
> HAProxy 'check' performs the lookup in dns.c the validation on the Answer
> domain with memcmp fails.
>
> I'm trying to understand what system is at fault here; the DNS server for
> not responding with the same case as the query, or HAProxy which should be
> performing a case insensitive match.
> I have made some test changes to src/dns.c to implement case insensitive
> matching in line 260 (in dns_resolve_recv) and unifying case before
> returning in dns_read_name. After these changes I can no longer reproduce
> the problem. I'm happy to share my patch file, but expect that your own
> libs and implementation will be cleaner.
> Relevant RFC: https://tools.ietf.org/html/rfc4343#section-3
>
> The current viable workaround appears to be simply matching the case that
> the DNS server is configured to reply with. For us this means specifying
> something like 'Server.db.example.com' instead of 'server.db.example.com'
> in haproxy.cfg.
>
>
> Reproduction steps:
> * Use 'check' and 'resolvers' in server section to enable
> post-initialisation dns lookups.
> * Have the DNS resolver reply in upper/lower/mixed case that does not
> match config file. (I can share a small python script that can be used to
> test this)
> The initial resolution during config read is fine, as this is done via
> libc. The subsequent DNS resolutions during checks fail and eventually set
> the server as offline.
>
> ---
> Sample configuration to reproduce:
> defaults
> log global
> mode tcp
> timeout connect 10s
> timeout client 1m
> timeout server 1m
> timeout check 10s
>
> resolvers dns-resolver
> nameserver ns1 127.0.0.1:1153
> resolve_retries 3
> timeout retry 1s
> hold valid 2s # small, so we can reproduce quickly
> hold other 10s
>
> frontend fe15000
> bind :15000
> default_backend be15000
>
> backend be15000
> server dest15000 example.com:5000 check resolvers dns-resolver
> init-addr libc,none
> ---
>
> Sample DNS response that triggers the issue:
> (Note the reply CaSe does not match query. I can also provide a simple
> Python server that performs uppercase in its reply, for replication of
> this.)
> ---
> $ dig @127.0.0.1 -p 1153 example.com
> <snip>
> ;; QUESTION SECTION:
> ;EXAMPLE.COM. IN A
>
> ;; ANSWER SECTION:
> EXAMPLE.COM. 60 IN A 127.0.0.1
> <snip>
>
>
> Thanks for any assistance,
> Dale Smith
>
>

Hi Dale,

Thanks for the report!
Please share your patch here and I'll have a look, so we could merge it.

Baptiste
↧

Re: resolvers - resolv.conf fallback

April 3, 2018, 9:50 am
$
0
0
On Mon, Apr 2, 2018 at 5:09 PM, Ben Draut <drautb@gmail.com> wrote:

> Assuming no one else is already working on the feature, I'd like to
> contribute
> the change to have the resolvers section fall back to parsing
> /etc/resolv.conf
> when no nameserver directives are present.
>
> This was previously discussed here: https://www.mail-archive
> .com/haproxy@formilux.org/msg28626.html.
> (Jim Freeman and I are colleagues.)
>
> I've been surveying the code to see how it could be implemented. I think it
> would make sense to register a 'post_section_parser' for the resolvers
> section
> that would add the nameservers from /etc/resolv.conf if no nameservers were
> specified in the section. As Jim pointed out previously, libresolv could
> be used
> to parse the file. If that's undesirable for some reason, we could parse it
> ourselves.
>
> I'm new to the codebase, so I'm open to any suggestions or guidance anyone
> may have.
>
> Thanks,
>
> Ben
>
>

Hi Ben,

I welcome this feature, though I have a few comments:
- I have nothing against libresolv, but I think this function should be
implemented natively in HAProxy
- (for Lukas) what do you think is better, a configuration option to
trigger parsing of resolv.conf or as proposed, if no nameserver are found,
we use resolv.conf as a failback?

As the maintainer of the DNS code in HAProxy, don't hesitate to ask me any
questions.

Baptiste
↧

[BUG][PATCH] fd: fix handling of poller updates

April 3, 2018, 10:40 am
$
0
0
Hi,

The attached patch attempts to fix the way we handle the update_mask bit.
Clearing that bit in fd_insert() may lead to entries being inserted twice
in fd_updt. Instead, make sure the pollers clear that bit once they are
done with the entry.

Regards,

Olivier

From 348ce4601eb92b01c098b54e7fadb9822fd8d15f Mon Sep 17 00:00:00 2001
From: Olivier Houchard <ohouchard@haproxy.com>
Date: Tue, 3 Apr 2018 19:06:18 +0200
Subject: [PATCH] BUG/MINOR: fd: Don't clear the update_mask in fd_insert.

Clearing the update_mask bit in fd_insert may lead to duplicate insertion
of fd in fd_updt, that could lead to a write past the end of the array.
Instead, make sure the update_mask bit is cleared by the pollers no matter
what.

This should big backported to 1.8.
---
include/proto/fd.h | 1 -
src/ev_epoll.c | 2 +-
src/ev_kqueue.c | 2 +-
src/ev_poll.c | 2 +-
src/ev_select.c | 2 +-
5 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/proto/fd.h b/include/proto/fd.h
index 0f59df661..6c9cfe701 100644
--- a/include/proto/fd.h
+++ b/include/proto/fd.h
@@ -445,7 +445,6 @@ static inline void fd_insert(int fd, void *owner, void (*iocb)(int fd), unsigned
fdtab[fd].owner = owner;
fdtab[fd].iocb = iocb;
fdtab[fd].ev = 0;
- fdtab[fd].update_mask &= ~tid_bit;
fdtab[fd].linger_risk = 0;
fdtab[fd].cloned = 0;
fdtab[fd].thread_mask = thread_mask;
diff --git a/src/ev_epoll.c b/src/ev_epoll.c
index b98ca8ca8..a8e57973f 100644
--- a/src/ev_epoll.c
+++ b/src/ev_epoll.c
@@ -74,13 +74,13 @@ REGPRM2 static void _do_poll(struct poller *p, int exp)
for (updt_idx = 0; updt_idx < fd_nbupdt; updt_idx++) {
fd = fd_updt[updt_idx];

+ HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);
if (!fdtab[fd].owner) {
activity[tid].poll_drop++;
continue;
}

en = fdtab[fd].state;
- HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);

if (fdtab[fd].polled_mask & tid_bit) {
if (!(fdtab[fd].thread_mask & tid_bit) || !(en & FD_EV_POLLED_RW)) {
diff --git a/src/ev_kqueue.c b/src/ev_kqueue.c
index cc96307b0..a103ece9d 100644
--- a/src/ev_kqueue.c
+++ b/src/ev_kqueue.c
@@ -47,13 +47,13 @@ REGPRM2 static void _do_poll(struct poller *p, int exp)
for (updt_idx = 0; updt_idx < fd_nbupdt; updt_idx++) {
fd = fd_updt[updt_idx];

+ HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);
if (!fdtab[fd].owner) {
activity[tid].poll_drop++;
continue;
}

en = fdtab[fd].state;
- HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);

if (!(fdtab[fd].thread_mask & tid_bit) || !(en & FD_EV_POLLED_RW)) {
if (!(fdtab[fd].polled_mask & tid_bit)) {
diff --git a/src/ev_poll.c b/src/ev_poll.c
index edcfe6565..6093b652b 100644
--- a/src/ev_poll.c
+++ b/src/ev_poll.c
@@ -65,13 +65,13 @@ REGPRM2 static void _do_poll(struct poller *p, int exp)
for (updt_idx = 0; updt_idx < fd_nbupdt; updt_idx++) {
fd = fd_updt[updt_idx];

+ HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);
if (!fdtab[fd].owner) {
activity[tid].poll_drop++;
continue;
}

en = fdtab[fd].state;
- HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);

/* we have a single state for all threads, which is why we
* don't check the tid_bit. First thread to see the update
diff --git a/src/ev_select.c b/src/ev_select.c
index 6e834678d..163a45839 100644
--- a/src/ev_select.c
+++ b/src/ev_select.c
@@ -57,13 +57,13 @@ REGPRM2 static void _do_poll(struct poller *p, int exp)
for (updt_idx = 0; updt_idx < fd_nbupdt; updt_idx++) {
fd = fd_updt[updt_idx];

+ HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);
if (!fdtab[fd].owner) {
activity[tid].poll_drop++;
continue;
}

en = fdtab[fd].state;
- HA_ATOMIC_AND(&fdtab[fd].update_mask, ~tid_bit);

/* we have a single state for all threads, which is why we
* don't check the tid_bit. First thread to see the update
--
2.14.3
↧
Search

Re: [BUG][PATCH] fd: fix handling of poller updates

April 3, 2018, 10:50 am
$
0
0
On Tue, Apr 03, 2018 at 07:33:57PM +0200, Olivier Houchard wrote:
> Hi,
>
> The attached patch attempts to fix the way we handle the update_mask bit.
> Clearing that bit in fd_insert() may lead to entries being inserted twice
> in fd_updt. Instead, make sure the pollers clear that bit once they are
> done with the entry.

Now merged, thanks!

Willy
↧
↧

Error log format

April 3, 2018, 5:10 pm
$
0
0
Hi,


Is it possible to change the format of the error logs? I was looking to filter out some of the fields that are printed when error logs are generated. I was able to do so for regular logs, but was not able to do so for error logs. The documentation does seem to indicate that it can't be done. But wanted to make sure that is the case.


Thanks,

Sushma
↧

有（发票）代开 需要联系18265777082 微信同号QQ2137175988

April 3, 2018, 7:40 pm
↧

No enabled listener found and reloads triggered an inconsistent state.

April 4, 2018, 1:20 am
$
0
0
Hi there,

We had an issue recently, using 1.8.5. For some reason we ended up entering in the "No enabled listener found" state (I guess the config file was incomplete, being written at that time, something like that).

Here are the logs:

Apr 03 17:51:49 hostname systemd[1]: Reloaded HAProxy Load Balancer.
Apr 03 17:54:22 hostname haproxy[27090]: [WARNING] 092/175149 (27090) : Reexecuting Master process
Apr 03 17:54:22 hostname haproxy[27090]: [ALERT] 092/175422 (27090) : [/usr/sbin/haproxy.main()] No enabled listener found (check for 'b
Apr 03 17:54:22 hostname haproxy[27090]: [WARNING] 092/175422 (27090) : Reexecuting Master process in waitpid mode
Apr 03 17:54:22 hostname haproxy[27090]: [WARNING] 092/175422 (27090) : Reexecuting Master process
Apr 03 17:54:22 hostname systemd[1]: Reloaded HAProxy Load Balancer.

Subsequent reloads were OK.

The issue here is that it lets HAProxy in an inconsistent state: connections are almost always in timeout, including the one on the Unix socket, the healtcheck endpoint set using monitor-uri, etc., until a real stop/start is done (meaning the parent/worker is restarted itself).
Doing reloads doesn't fix here.

Any hints?

Thanks,

Pierre
↧

Re: [PATCH] BUG/MINOR: email-alert: Set the mailer port during alert initialization

April 4, 2018, 1:50 am
$
0
0
On Tue, Mar 27, 2018 at 04:04:40PM +0200, Christopher Faulet wrote:
> Hi,
>
> This patch fixes an issue about email alerts reported by Johan. It must be
> backported in 1.8.
>
> Johan, could you confirm it fixes the bug ?

Out of response I've merged it now, thank you Christopher.

Willy
↧
↧

Re: DNS resolver and mixed case responses

April 4, 2018, 2:40 am
$
0
0
On Tue, 3 Apr 2018 at 17:35 Baptiste <bedis9@gmail.com> wrote:

>
> Hi Dale,
>
> Thanks for the report!
> Please share your patch here and I'll have a look, so we could merge it.
>
> Baptiste
>

Hi Baptiste,

I've attached a patch file for haproxy-1.7 that performs the case
insensitive match instead of a direct memcmp. This resolves the issue in my
testing, I'd be interested in your thoughts on this; and happy to rework or
re-test any suggestions you have for the patch.

I previously mentioned an additional dns_toupper within dns_read_name, but
this does not appear to be necessary to resolve this particular issue so I
have removed it.

Regards,
Dale Smith
↧

Re: resolvers - resolv.conf fallback

April 4, 2018, 3:40 am
$
0
0
Hello Baptiste,


> - (for Lukas) what do you think is better, a configuration option to trigger
> parsing of resolv.conf or as proposed, if no nameserver are found, we use
> resolv.conf as a failback?


I don't think we need a config knob for this; currently we don't do
anything when no nameservers are configured; that behavior combined
with the by-default enabled libc resolver at startup can cause some
confusion.

Transitioning to a resolv.conf fallback is the correct thing to do here imho.


Just:
- only fallback if no resolvers are configured in haproxy configuration
- don't fallback if configured resolvers are unresponsive
- update the documentation at the same time


I don't think we need a new config know.



cheers,

lukas
↧
Search

Re: DNS resolver and mixed case responses

April 4, 2018, 7:40 am
$
0
0
Dale,

Am 03.04.2018 um 16:17 schrieb Dale Smith:
> I'm trying to understand what system is at fault here; the DNS server for
> not responding with the same case as the query, or HAProxy which should be
> performing a case insensitive match.

This is left unspecified in the standards, but on the other hand there
is this Internet Draft:
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 which wants to
mandate case preserval to make DNS spoofing harder by introducing more
entropy in the DNS request.

I recommend to fix your internal DNS server, because case preserving
behaviour seems to be somewhat expected according to a quick Google search.

Best regards
Tim Düsterhus
↧

Re: Rejected connections not getting counted in stats

April 4, 2018, 9:10 am
$
0
0
Hi Errikos,


On 26/03/2018 13:03, Errikos Koen wrote:
> Hello,
>
> I have a frontend whitelisted by IP with the following rules:
>
> acl whitelist src -f /etc/haproxy/whitelist.lst
> tcp-request connection reject unless whitelist
>
> and while documentation
> <https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-tcp-request%20connection&gt; suggests
> I would be able to see the rejected connections counted in stats
> (quote: they are accounted separately for in the stats, as "denied
> connections"), those are stuck at 0.
>
> The whitelist appears to be working ok, making a request from a non
> whitelisted IP results in:
>
> $ curl -v http://hostname
> * About to connect() to hostname port 80 (#0)
> *   Trying xxx.xxx.xxx.xxx...
> * connected
> * Connected to hostname (xxx.xxx.xxx.xxx) port 80 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.26.0
> > Host: hostname
> > Accept: */*
> >
> * additional stuff not fine transfer.c:1037: 0 0
> * Recv failure: Connection reset by peer
> * Closing connection #0
> curl: (56) Recv failure: Connection reset by peer
>
> and whitelisted IPs work ok.
>
> I am running a self compiled haproxy 1.8.4 (with make options
> USE_PCRE=1 TARGET=linux2628 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1) on
> Debian 8 with 3.16.0-5-amd64 kernel.
>
> Any ideas?
>
> Thanks
> --
> Errikos Koen,
> Cloud Architect
> www.pamediakopes.gr http://www.pamediakopes.gr

It works for me using the same version and build options.
Maybe you are looking to the wrong counter.
The one in the stats page is about "denied requests" (this is about http
requests) while you should be looking for "denied connections", you can
find more about this here:
https://cbonte.github.io/haproxy-dconv/1.8/management.html#9.1
According to the doc, the "denied connections" is the 81th field
(counting from 0) so using the following command will help track the
counter:
watch  'echo "show stat" | socat stdio  < haproxy-socket-path > | cut -d
"," -f 1-2,82 | column -s, -t'

++

--
Moemen MHEDHBI
↧
↧

Re: Haproxy 1.8.4 crashing workers and increased memory usage

April 5, 2018, 2:50 am
$
0
0
Hi Willy

>>>> There are very few abort() calls in the code :
>>>>   - some in the thread debugging code to detect recursive locks ;
>>>>   - one in the cache applet which triggers on an impossible case very
>>>>     likely resulting from cache corruption (hence a bug)
>>>>   - a few inside the Lua library
>>>>   - a few in the HPACK decompressor, detecting a few possible bugs there

After playing around with some config changes we managed to not have haproxy throw the "worker <pid> exited with code 134" error for at least a day. Which is a long time as before we had this error at least 5 times a day...

The line we removed from our config to get this result was:
compression algo gzip

Could it be a locking issue in the compression code? I'm going to run a few more days without compression enabled, but for now this looks promising!

Thanks,
Frank
↧

Re: Haproxy 1.8.4 crashing workers and increased memory usage

April 5, 2018, 6:10 am
$
0
0
Hi Frank,

On Thu, Apr 05, 2018 at 09:41:25AM +0000, Frank Schreuder wrote:
> Hi Willy
>
> >>>> There are very few abort() calls in the code :
> >>>>   - some in the thread debugging code to detect recursive locks ;
> >>>>   - one in the cache applet which triggers on an impossible case very
> >>>>     likely resulting from cache corruption (hence a bug)
> >>>>   - a few inside the Lua library
> >>>>   - a few in the HPACK decompressor, detecting a few possible bugs there
>
> After playing around with some config changes we managed to not have haproxy
> throw the "worker <pid> exited with code 134" error for at least a day. Which
> is a long time as before we had this error at least 5 times a day...

Great!

> The line we removed from our config to get this result was:
> compression algo gzip

Hmmm interesting.

> Could it be a locking issue in the compression code? I'm going to run a few
> more days without compression enabled, but for now this looks promising!

In fact, the locking is totally disabled when not using compression, so
it cannot be an option. Also, most of the recently fixed bugs may only
be triggered with H2 or threads, none of which you're using. I rechecked
the compression code to try to spot anything obvious, but nothing popped
out :-/

All I can strongly recommend if you retry with compression enabled is to
do it with latest 1.8 release. I'm currently checking that I didn't miss
anything to issue 1.8.6 hopefully today. If it still dies, this will at
least rule out the possible side effects of a few of the bugs we've fixed
since, all of which were really tricky.

Cheers,
Willy
↧

[ANNOUNCE] haproxy-1.8.6

April 5, 2018, 7:30 am
$
0
0
Hi,

HAProxy 1.8.6 was released on 2018/04/05. It added 23 new commits
after version 1.8.5.

It fixes several bugs, two of which are considered of major severity since
they can cause the process to randomly crash. One is in the HTTP/2 code and
the other one in the cache, both since the very first 1.8 release.

Among the other more or less visible issues fixed in this version, I noted :
- a failure to properly release some H2 streams, causing some H2 connections
never to time out, hence old processes never to exit upon reload ;

- a risk of occasional timeouts at the end of large transfers over H2, once
the file has been completely sent but there is no more room to perform the
shutdown ;

- pure TCP checks appearing as in progress for the whole duration of the
check (the connection was validated only on the check timeout) ;

- unbreakage of email alerts appearing as a side effect of a tcp-check fix
in 1.8.5

- some SPOE initialization and timeout handling improvements

As usual, every 1.8 user is strongly advised to upgrade to this last version,
especially if you're using HTTP/2, the cache, or are experiencing strange
issues or crashes.

Please find the usual URLs below :
Site index : http://www.haproxy.org/
Discourse : http://discourse.haproxy.org/
Sources : http://www.haproxy.org/download/1.8/src/
Git repository : http://git.haproxy.org/git/haproxy-1.8.git/
Git Web browsing : http://git.haproxy.org/?p=haproxy-1.8.git
Changelog : http://www.haproxy.org/download/1.8/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (3):
BUG/MINOR: email-alert: Set the mailer port during alert initialization
BUG/MINOR: spoe: Initialize variables used during conf parsing before any check
BUG/MINOR: spoe: Don't release the context buffer in .check_timeouts callbaclk

Ilya Shipitsin (1):
BUILD/MINOR: fix build when USE_THREAD is not defined

Olivier Houchard (1):
BUG/MINOR: fd: Don't clear the update_mask in fd_insert.

Thierry Fournier (2):
BUG/MINOR: lua: the function returns anything
BUG/MINOR: lua funtion hlua_socket_settimeout don't check negative values

Willy Tarreau (16):
MINOR: cli/threads: make "show fd" report thread_sync_io_handler instead of "unknown"
MINOR: cli: make "show fd" report the mux and mux_ctx pointers when available
BUILD/MINOR: cli: fix a build warning introduced by last commit
BUG/MINOR: hpack: fix harmless use of uninitialized value in hpack_dht_insert
CLEANUP: h2: rename misleading h2c_stream_close() to h2s_close()
MINOR: h2: provide and use h2s_detach() and h2s_free()
BUG/MAJOR: h2: remove orphaned streams from the send list before closing
MINOR: h2: always call h2s_detach() in h2_detach()
MINOR: h2: fuse h2s_detach() and h2s_free() into h2s_destroy()
BUG/MEDIUM: h2/threads: never release the task outside of the task handler
BUG/MEDIUM: h2: don't consider pending data on detach if connection is in error
BUILD/MINOR: threads: always export thread_sync_io_handler()
BUG/MEDIUM: h2: always add a stream to the send or fctl list when blocked
BUG/MINOR: checks: check the conn_stream's readiness and not the connection
BUG/MINOR: cache: fix "show cache" output
BUG/MAJOR: cache: fix random crashes caused by incorrect delete() on non-first blocks

---
↧
Viewing all 11674 articles
Browse latest View live
Search