On 11 December 2014 at 07:58, Kasim ktu...@gmail.com wrote:
Hi,
I am running haproxy on Ubuntu 14.04. After I added following config:
stick-table type ip size 2m expire 5m
stick on src
Taking out a server and reloading haproxy still sends traffic to that server
ever after the stick table
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take a few
seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork; let's call that
CRASHTIME. Previously we'd been using 1.5.3 on the same hardware for some
months without crashes. Once the crashes started we moved to
Hello,
2014-12-11 15:26 GMT+01:00 David Adams dr...@yahoo.com:
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take a
few seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork;
When you say crash, do you mean Segfault ?
Have you tried generating a coredump of
2014-12-11 15:35 GMT+01:00 Olivier webmas...@ajeux.com:
When you say crash, do you mean Segfault ?
Also check /var/log/messages to see if OOM Killer is not involved in what
you are experiencing.
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or
take a few seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like
clockwork; let's call that CRASHTIME. Previously we'd been using 1.5.3
on the same hardware for some months without crashes. Once the crashes
started
Hi David,
Le 11/12/2014 15:26, David Adams a écrit :
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take a
few seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork; let's
call that CRASHTIME. Previously we'd been using 1.5.3 on the same hardware
for some
Le 11/12/2014 16:20, cyril.bo...@free.fr a écrit :
1am, 5am, 9am,
1pm, 5pm, 9pm
1.5.9
= coincidence ? This really make me think of a script.
I mean a script *issue* ;-)
--
Cyril Bonté
Nothing in /var/log/messages related to this. The only unusual thing is it
reporting that haproxy is starting up again after it stopped.
On Thursday, 11 December 2014, 14:37, Olivier webmas...@ajeux.com wrote:
2014-12-11 15:35 GMT+01:00 Olivier webmas...@ajeux.com:
When you say
On Thu, Dec 11, 2014 at 4:22 PM, cyril.bo...@free.fr wrote:
Le 11/12/2014 16:20, cyril.bo...@free.fr a écrit :
1am, 5am, 9am,
1pm, 5pm, 9pm
1.5.9
= coincidence ? This really make me think of a script.
I mean a script *issue* ;-)
--
Cyril Bonté
mhh
David may have enabled the
Meaning the first crash was with 1.5.3, correct?
Yes. It started happening with 1.5.3 (which had been stable for a while), and
continues to happen with 1.5.9.
Ok, a part from the informations Oliver requested please provide:
- haproxy -vv output
HA-Proxy version 1.5.9 2014/11/25Copyright
The process just disappears.
I've execute those commands and will see if it generates a coredump when it
does it again, which will be in 90 minutes time.
On Thursday, 11 December 2014, 14:35, Olivier webmas...@ajeux.com wrote:
Hello,
2014-12-11 15:26 GMT+01:00 David Adams
Yes, I am quite sure it's something external to the haproxy process which is
somehow interfering with it, but I can't figure out what. As I mentioned,
looking at a list of processes before and after haproxy stops doesn't reveal
any changes in what was running, i.e. it's not like some script
On Thu, 11 Dec 2014, 16:34:02 +0100, David Adams wrote:
Nothing in /var/log/messages related to this. The only unusual thing is it
reporting that haproxy is starting up again after it stopped.
what type of init process are you using (sysvinit vs. systemd)? Please
also check any
On Thu, Dec 11, 2014 at 10:40 AM, David Adams dr...@yahoo.com wrote:
Yes, I am quite sure it's something external to the haproxy process which is
somehow interfering with it, but I can't figure out what. As I mentioned,
looking at a list of processes before and after haproxy stops doesn't
David:
You could try running strace -faep HAPROXY_PID -o /tmp/haproxy.strace from
1 minute before the process is getting killed. Then examine the output
file for clues. I might not have the options 100% correct.
-Jerry
Jerry Champlin
Absolute Performance Inc.
Phone: 303-565-4401
--
Enabling
On 12/11/2014 04:20 PM, cyril.bo...@free.fr wrote:
Hi David,
Le 11/12/2014 15:26, David Adams a écrit :
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take a few
seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork; let's call that
CRASHTIME. Previously we'd
On 12/11/2014 11:50 AM, Jonathan Matthews wrote:
On 11 December 2014 at 07:58, Kasim ktu...@gmail.com wrote:
Hi,
I am running haproxy on Ubuntu 14.04. After I added following config:
stick-table type ip size 2m expire 5m
stick on src
Taking out a server and reloading haproxy still sends
On Thu, Dec 11, 2014 at 12:03 PM, David Adams dr...@yahoo.com wrote:
I tried this. I ran it like this:
/usr/local/sbin/haproxy -db -f /etc/haproxy/haproxy.cfg
which obviously didn't return as the process ran. Then at the crashtime (a
few seconds past 17:00), that process terminated and the
❦ 11 décembre 2014 17:03 GMT, David Adams dr...@yahoo.com :
I tried this. I ran it like this:
/usr/local/sbin/haproxy -db -f /etc/haproxy/haproxy.cfg
which obviously didn't return as the process ran. Then at the
crashtime (a few seconds past 17:00), that process terminated and the
I will do next time. And yes, was planning to run strace.
Do I need to recompile to enable coredumps?
On Thursday, 11 December 2014, 17:19, Tait Clarridge t...@clarridge.ca
wrote:
On Thu, Dec 11, 2014 at 12:03 PM, David Adams dr...@yahoo.com wrote:
I tried this. I ran it like
I will do next time. And yes, was planning to run strace.
Do I need to recompile to enable coredumps?
No, you just adjust ulimit before you start, and make
sure you didn't strip (as in the command strip) the
executable.
Then check the core with:
gdb path/to/the/binary path/to/the/core
[PATCH] DOC: httplog does not support 'no'
Modified: doc/configuration.txt
doc/configuration.txt | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index aa6baab..5dc3afa 100644
--- a/doc/configuration.txt
+++
On 11 Dec 2014 14:27, David Adams dr...@yahoo.com wrote:
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take
a few seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork; let's
call that CRASHTIME. Previously we'd been using 1.5.3 on the same hardware
for some
Am 11.12.2014 um 15:26 schrieb David Adams dr...@yahoo.com
mailto:dr...@yahoo.com:
We are running 1.5.9 on Centos 6.5. It crashes 10 seconds (give or take a
few seconds) after 1am, 5am, 9am, 1pm, 5pm and 9pm, like clockwork; let's
call that CRASHTIME. Previously we'd been using 1.5.3
I have an easy workarround : rename the version to out of hour range
numbers : 25.26.27 ;)
On Thu, Dec 11, 2014 at 4:55 PM, Emeric Brun eb...@haproxy.com wrote:
On 12/11/2014 04:20 PM, cyril.bo...@free.fr wrote:
Hi David,
Le 11/12/2014 15:26, David Adams a écrit :
We are running 1.5.9 on
I ran strace on it just before CRASHTIME. It stopped on cue, with an exit code
of 134.
The strace output is here: haproxy strace - Pastebin.com
As you'll see, it looks very strange - immediately after a series of futex
calls (I've no idea of their significance, only noting that they don't
❦ 12 décembre 2014 02:08 GMT, David Adams dr...@yahoo.com :
I ran strace on it just before CRASHTIME. It stopped on cue, with an
exit code of 134.
The strace output is here: haproxy strace - Pastebin.com
As you'll see, it looks very strange - immediately after a series of
futex calls
27 matches
Mail list logo
