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 fe
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
Hi Willy,
> > > A few more things on the core dumps :
> > > - they are ignored if you have a chroot statement in the global section
> > > - you need not to use "user/uid/group/gid" otherwise the system also
> > > disables core dumps
> >
> > I'm using chroot and user/group in my config, so I'
Hi Willy and Tim,
> > >> 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 could co
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
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
6 matches
Mail list logo
