Re: [PATCH] BUG/MINOR: systemd: ignore daemon mode

On Tue, Nov 21, 2017 at 11:45:29AM +0100, Lukas Tribus wrote: > Since we switched to notify mode in the systemd unit file in commit > d6942c8, haproxy won't start if the daemon keyword is present in the > configuration. > > Update the unit file with -db to disable background mode in all >

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Tue, Nov 21, 2017 at 11:28:55AM +0100, Willy Tarreau wrote: > On Tue, Nov 21, 2017 at 11:19:41AM +0100, William Lallemand wrote: > > I don't like the idea of the "daemon" keyword being ignored, > > We already do that with -D which ignores "debug" for example. The command > line purposely has

[PATCH] BUG/MINOR: systemd: ignore daemon mode

Since we switched to notify mode in the systemd unit file in commit d6942c8, haproxy won't start if the daemon keyword is present in the configuration. Update the unit file with -db to disable background mode in all circumstances and add a note in the documentation. ---

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hello, 2017-11-21 8:39 GMT+01:00 William Lallemand : > On Tue, Nov 21, 2017 at 07:16:19AM +0100, Willy Tarreau wrote: >> >> I really don't like this. My fears with becoming more systemd-friendly >> was that we'd make users helpless when something decides not to work >>

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hi Lukas, On Tue, Nov 21, 2017 at 11:12:45AM +0100, Lukas Tribus wrote: > > I suggest we configure it to a greater value per default, it can be set to > > infinity too, but I don't like the idea. > > That's not it, the hold-off timer is only a consequence of this > problem. OK but if it's

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

On Tue, Nov 21, 2017 at 11:12:45AM +0100, Lukas Tribus wrote: > Hello, > > 2017-11-21 8:39 GMT+01:00 William Lallemand : > > That's not it, the hold-off timer is only a consequence of this > problem. I believe the notification does not work in my case, which is > why for

Re: [PATCH v3 1/1] MEDIUM: mworker: Add systemd `Type=notify` support

Hello, 2017-11-21 11:18 GMT+01:00 Willy Tarreau : >> That's not it, the hold-off timer is only a consequence of this >> problem. > > OK but if it's really 100ms, it can be a problem for people loading GeoIP > maps of millions of entries, or large configs (the largest I saw had

[PATCH v2] BUG/MINOR: systemd: ignore daemon mode

Since we switched to notify mode in the systemd unit file in commit d6942c8, haproxy won't start if the daemon keyword is present in the configuration. This change makes sure that haproxy remains in foreground when using systemd mode and adds a note in the documentation. ---

incorrect search for a server's crt in ca-base

Hi! In 1.7.9 with crt-base and ca-base in global haproxy try to search crt for server in ca-base. In bind all work as expected. If I specify the full path for crt in server - it's ok. # cat /tmp/haproxy.cfg global ca-base /etc/haproxy/ca-base crt-base /etc/haproxy/crt-base defaults mode

Re: 4xx statistics made useless through health checks?

Hi Lukas, thanks — was just about to reply to myself, but you beat me to it ;) > Yes, we have "option dontlognull" for that: > http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-option%20dontlognull We can get rid of the logging via dontlognull, of course. Was about to mention that

Re: haproxy-1.8-rc4 - FreeBSD 11.1 - master-worker daemon parent staying alive/process-owner

Hi William, I was intending to use the new feature to pass open sockets to the next haproxy process. And thought that master-worker is a 'requirement' to make that work as it would manage the transferal of sockets. Now i'm thinking thats not actually how its working at all.. I could

Re: 4xx statistics made useless through health checks?

Hi, On 17-11-21 14:20:39, Daniel Schneller wrote: > > On 21. Nov. 2017, at 14:08, Lukas Tribus wrote: > > [...] > > Instead of hiding specific errors counters, why not send an actual > > HTTP request that triggers a 200 OK response? So health checking is > > not exempt from the

Re: [PATCH v2] BUG/MINOR: systemd: ignore daemon mode

Lukas, Am 21.11.2017 um 12:39 schrieb Lukas Tribus: > This change makes sure that haproxy remains in foreground when using > systemd mode and adds a note in the documentation. > --- > doc/configuration.txt | 3 ++- > src/haproxy.c | 2 +- > 2 files changed, 3 insertions(+), 2

Re: 4xx statistics made useless through health checks?

Hi Daniel, Op 21-11-2017 om 14:20 schreef Daniel Schneller: On 21. Nov. 2017, at 14:08, Lukas Tribus wrote: [...] Instead of hiding specific errors counters, why not send an actual HTTP request that triggers a 200 OK response? So health checking is not exempt from the statistics

Re: 4xx statistics made useless through health checks?

Hi Pieter, >> Good point. I wanted to avoid, however, having these “high level” health >> checks from the many many sidecars being routed through to the actual >> backends. >> Instead, I considered it enough to “only” check if the central haproxy is >> available. In case it is, the sidecars

Re: 4xx statistics made useless through health checks?

> On 21. Nov. 2017, at 14:08, Lukas Tribus wrote: > [...] > Instead of hiding specific errors counters, why not send an actual > HTTP request that triggers a 200 OK response? So health checking is > not exempt from the statistics and only generates error statistics > when actual

Re: 4xx statistics made useless through health checks?

Hallo Daniel, 2017-11-21 10:08 GMT+01:00 Daniel Schneller : > However, I see lots of 4xx errors counted on the central LBs. I have tracked > those down to being caused by the health checks of all the sidecars, > checking in every few seconds to see if their

Re: 4xx statistics made useless through health checks?

Hello, 2017-11-21 13:54 GMT+01:00 Daniel Schneller : > However, I still wonder if there is a good way to discern these from > “actual"bad requests in the stats, so that we can rely on the error counters > to show “real” problems. > > Some kind of

Re: [PATCH v2] BUG/MINOR: systemd: ignore daemon mode

On Tue, Nov 21, 2017 at 12:39:34PM +0100, Lukas Tribus wrote: > Since we switched to notify mode in the systemd unit file in commit > d6942c8, haproxy won't start if the daemon keyword is present in the > configuration. > > This change makes sure that haproxy remains in foreground when using >

haproxy 1.8-rc4: cache and HTTP/1.1 response for HTTP/1.0 request

Hi Willy and William, I ran some tests with the cache filter. In http_action_store_cache(), the code indicates that only HTTP/1.1 is cached. This explains why I failed on my first tests with apachebench :) The protocol version is checked on the request side. Can't we rely on the response side

[RFC PATCH] BUG/MINOR: h2: use valid stream id in GOAWAY

Since af1e4f5167 ("MEDIUM: h2: perform a graceful shutdown on "Connection: close"") we send GOAWAY with last stream identifier set to 2^31-1, as per the RFC suggestion [1]. However that is only part of what the RFC suggests if we want to close the connection gracefully; after at least 1 RTT we

Re: [RFC PATCH] BUG/MINOR: h2: use valid stream id in GOAWAY

Hi Lukas, On Wed, Nov 22, 2017 at 01:43:32AM +0100, Lukas Tribus wrote: > Since af1e4f5167 ("MEDIUM: h2: perform a graceful shutdown on "Connection: > close"") we send GOAWAY with last stream identifier set to 2^31-1, as per > the RFC suggestion [1]. However that is only part of what the RFC