Am 12.01.19 um 08:47 schrieb Willy Tarreau:
>> The following issue was closed ... :
>> from another repository, just because I referenced the issue
>> prepending the word "Fix":
On Sat, Jan 12, 2019 at 12:24:23PM +0100, Tim Düsterhus wrote:
> > This one is less of a problem because the likelihood that someone writes
> > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
> > they do it on purpose to annoy us of course.
> It would only
Am 12.01.19 um 02:53 schrieb Lukas Tribus:
> As our intention I believe is to keep the issue open until all
> affected branches are fixed, this github feature is a little
> inconvenient. But I guess we can just refer to the issue by prepending
> it with "issue" or "bug", so GH doesn't see
Am 07.01.19 um 13:40 schrieb Emerson Gomes:
> Just to update you, I have tried the patch, and while I didnt see any new
> occurences of the underflow, HAProxy started to crash constantly...
> Jan 07 10:32:37 afrodite haproxy: [ALERT] 006/103237 (14364) :
> Current worker #1
On Fri, Jan 11, 2019 at 01:05:15PM +0200, Assen Totin wrote:
> Hi, everybody!
> I'm facing an issue with a somewhat weird/broken client and I'm looking for
> some advise on it.
> The client opens a HTTPS session and sends its request (POST data in my
> case). The HTTPS part is fine. The
Am 12.01.19 um 12:45 schrieb Willy Tarreau:
>> This example makes me wonder, though: Should the various branches be
>> separate repositories on GitHub like on haproxy.org or should they be
>> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
>> haproxy/haproxy-1.8) for the mirror?
On Wed, Jan 09, 2019 at 07:23:42PM +0100, Olivier D wrote:
> Hello folks,
> Just wanted to raise an issue with a compilation error on HAProxy that I
> was able to solve by myself. Just wanted to know if this issue is
> haproxy-related or compiler-related (and if a fix should be
On Sat, Jan 12, 2019 at 01:00:33AM +0100, PiBa-NL wrote:
> Thanks for this 'change in behavior' ;). Indeed the mailbomb is fixed, and
> it seems the expected mails get generated and delivered, but a segfault also
> happens on occasion. Not with the regtest as it was, but with a few
On Wed, Jan 09, 2019 at 01:16:18PM +, Basha Mougamadou wrote:
> Using haproxy 1.8.16-5c3f237, for unknown reason, one of the process uses all
> the available cores.
>PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
> 25120 haproxy
On Sat, Jan 12, 2019 at 01:09:08PM +0100, Tim Düsterhus wrote:
> Am 12.01.19 um 12:45 schrieb Willy Tarreau:
> >> This example makes me wonder, though: Should the various branches be
> >> separate repositories on GitHub like on haproxy.org or should they be
> >> actual branches (e.g.
I've configured haproxy with htx and when i try to filter the stats webpage.
Sending this request: "GET /?;csv;scope=b1" to '2.0-dev0-762475e
2019/01/10' it will crash with the trace below.
1.9.0 and 1.9.1 are also affected.
Can someone take a look? Thanks in advance.
A regtest is
Hi Willy, Olivier,
Op 12-1-2019 om 13:11 schreef Willy Tarreau:
it is needed to prepend this at the beginning of chk_report_conn_err() :
We need to make sure that check->server is properly tested everywhere.
With a bit of luck
On Sat, Jan 12, 2019 at 09:30:39PM +0100, PiBa-NL wrote:
> Hi Willy, Olivier,
> Op 12-1-2019 om 13:11 schreef Willy Tarreau:
> > Hi Pieter,
> > it is needed to prepend this at the beginning of chk_report_conn_err() :
> > if (!check->server)
> > return;
Mail list logo