Hi,
ok, thanks.
This probably has to do with the changes regarding buffers.
If this is a lab setup, my suggestion would be you don't use the init
scripts to start haproxy, but start it manually from the haproxy
directory (ulimit -c unlimited; ./haproxy -f configfile), when haproxy
crashes it should generated a file named "core" in the haproxy directory.
Just make sure you start haproxy as root, it doesn't matter if it
downgrades privileges to "haproxy" after the start.
Thanks,
Lukas
Am 12.05.2016 um 02:23 schrieb Sasha Litvak:
Lukas,
1.6.3 didn't have any crashes. These crashes are sporadic and are not
happening under the load, there is very little traffic as we are not
running production yet. The proxy starts fine and can run for hours
with the crash.
Where would the core be generated? I set it up running as user
haproxy would I have to adjust limits for that user?
Thank you for all your help,
On Wed, May 11, 2016 at 4:02 PM, Lukas Tribus <lu...@gmx.net
<mailto:lu...@gmx.net>> wrote:
Hi Sasha,
so the crash happens sporadically after hours of production
traffic? Or does it crash right away after you start it?
You are saying this started with 1.6.4, what was the version you
used before and that worked fine? 1.6.3?
Before starting haproxy, enable core dumping like this:
ulimit -c unlimited
Confirm its unlimited (right before starting haproxy from this shell):
ulimit -c
Disabling compiler optimizations will make sure the generated
coredump is as meaningful as possible, you can do it like this:
make clean; make CFLAGS="-O0 -g -fno-strict-aliasing
-Wdeclaration-after-statement" TARGET=linux2628 USE_ZLIB=1
USE_OPENSSL=1 USE_PCRE=1
But be advised that there will be performance/cpu impact, so you
better monitor it.
When you have a coredump, you can provide a backtrace with gdb
like this:
gdb <haproxy-executable> <coredump>
and issuing a "bt full"
Regards,
Lukas
