Thanks Lukas,
It was indeed the option httpclose enabled only on that backend.
Greets,
Sander
On 2018-02-21 16:49, Lukas Tribus wrote:
Hello Sander,
make sure you use "option http-keep-alive" as http mode, specifically
httpclose will cause issue with H2.
If that's not it, please share the c
Hi all,
I'm running haproxy 1.8.4 with a heavy work load.
For some reason some workers die every now and then with the following error in
the log:
Feb 22 05:00:42 hostname haproxy[9950]: [ALERT] 052/045759 (9950) : Current
worker 3569 exited with code 134
We never saw this behavior on haproxy 1
Hi,
I am following up to check if you are interested in acquiring the "Attendees
List MWC 2018, Barcelona, Spain- Mar 2018.
We have identified 20,000 professionals are attending MWC 2018 through our
primary & social research.
Let me know if you would like to acquire 20,000 Attendees List? We ha
Frank,
Am 22.02.2018 um 13:00 schrieb Frank Schreuder:
> I'm running haproxy 1.8.4 with a heavy work load.
> For some reason some workers die every now and then with the following error
> in the log:
> Feb 22 05:00:42 hostname haproxy[9950]: [ALERT] 052/045759 (9950) : Current
> worker 3569 exit
This option takes away system calls that are unneeded for haproxy's
operation and thus is a good defense in depth measure.
There are more system call sets available in newer SystemD versions,
but using those would make SystemD ignore the whole option when they
are not supported. This patch adds a
I'm running this exact settings on my Debian Stretch machine using haproxy
1.8.x, without issues so far.
The first patch could cause issues for users that store their configuration
in /home or /root, but I consider this unlikely.
Tim Duesterhus (2):
MINOR: systemd: Add SystemD's Protect*= optio
While the haproxy workers usually are running chrooted the master
process is not. This patch is a pretty safe defense in depth measure
to ensure haproxy cannot touch sensitive parts of the file system.
ProtectSystem takes non-boolean arguments in newer SystemD versions,
but setting those would lea
Hi Tim,
>> I'm running haproxy 1.8.4 with a heavy work load.
>> For some reason some workers die every now and then with the following error
>> in the log:
>> Feb 22 05:00:42 hostname haproxy[9950]: [ALERT] 052/045759 (9950) : Current
>> worker 3569 exited with code 134
>>
>
> Code 134 implies t
Frank,
Am 22.02.2018 um 15:33 schrieb Frank Schreuder:
>> Code 134 implies the worker was killed with SIGABRT. You could check
>> whether there is a core dump.
>
> I don't have any core dumps.
Check whether coredumps are enabled using `ulimit -c`, often they are
disabled by default, because they
Hi guys,
On Thu, Feb 22, 2018 at 04:20:07PM +0100, Tim Düsterhus wrote:
> Frank,
>
> Am 22.02.2018 um 15:33 schrieb Frank Schreuder:
> >> Code 134 implies the worker was killed with SIGABRT. You could check
> >> whether there is a core dump.
> >
> > I don't have any core dumps.
>
> Check whethe
10 matches
Mail list logo