On Wed, May 18, 2016 at 08:58:25AM -0500, Sasha Litvak wrote:
> I have a core now. How and what can I send to you?
Excellent :-)
If it's less than a few megs, just compress it and send it to me/us over
e-mail. In all cases, don't send it to the list as it contains some sensitive
information! If
I have a core now. How and what can I send to you?
On Wed, May 18, 2016 at 8:54 AM, Willy Tarreau wrote:
> On Wed, May 18, 2016 at 08:48:05AM -0500, Sasha Litvak wrote:
> > Home directory for user haproxy or other permissible place had to be
> used
> > to start in order to store
On Wed, May 18, 2016 at 08:48:05AM -0500, Sasha Litvak wrote:
> Home directory for user haproxy or other permissible place had to be used
> to start in order to store a core file. While running in the non daemon
> mode killall -6 haproxy produced core. However editing /etc/init.d/haproxy
> as
Home directory for user haproxy or other permissible place had to be used
to start in order to store a core file. While running in the non daemon
mode killall -6 haproxy produced core. However editing /etc/init.d/haproxy
as below had no effect, i.e no core.
start() {
++ ulimit -c unlimited
On Wed, May 18, 2016 at 12:50:19PM +0200, Nenad Merdanovic wrote:
> Hey,
>
> On 5/18/2016 8:28 AM, Sasha Litvak wrote:
> > It is hard to reproduce, It took almost a week for it to crush and
> > produced no core. I did ulimit -c unlimited before start. Does it make
> > sense to go to back to
Hey,
On 5/18/2016 8:28 AM, Sasha Litvak wrote:
> It is hard to reproduce, It took almost a week for it to crush and
> produced no core. I did ulimit -c unlimited before start. Does it make
> sense to go to back to 1.6.3 or try git source ?
Make sure you set the fs.suid_dumpable=1 sysctl
It is hard to reproduce, It took almost a week for it to crush and
produced no core. I did ulimit -c unlimited before start. Does it make
sense to go to back to 1.6.3 or try git source ?
On Thu, May 12, 2016 at 2:11 AM, Lukas Tribus wrote:
> Hi,
>
>
> ok, thanks.
>
> This
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
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
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
I apologize the version is 1.6.5. I built it myself with zlib, openssl,
pcre and linux2628 and I run it on CentOS 6.7.
I had several crashes happening starting from 1.6.4 but they were related
to zlib which also was weird
Apr 21 15:11:25 node1lvs1-la kernel: haproxy[15586]: segfault at
Hello,
On 5/11/2016 10:16 AM, Alex Litvak wrote:
> Haproxy 1.6.15 crashes with following error
>
> haproxy[24074]: segfault at 3dbed94000 ip 003dbea897fb sp
> 7fffc7278e68 error 4 in libc-2.12.so[3dbea0+18a000]
>
>
Are you able to reliably reproduce this? Please post the output
Haproxy 1.6.15 crashes with following error
haproxy[24074]: segfault at 3dbed94000 ip 003dbea897fb sp
7fffc7278e68 error 4 in libc-2.12.so[3dbea0+18a000]
13 matches
Mail list logo