Hi Cyril,
On Thu, Jan 16, 2014 at 10:48:10PM +0100, Cyril Bonté wrote:
Hi Willy,
Le 15/01/2014 01:08, Willy Tarreau a écrit :
On Tue, Jan 14, 2014 at 12:25:37PM -0800, Steve Ruiz wrote:
Patched and confirmed in our environment that this is now working / seems
to have fixed the issue.
On Fri, Jan 17, 2014 at 10:47:01AM +0100, Willy Tarreau wrote:
So I might have broken something in the way to count the try value,
ending up with zero being selected and nothing done. Unfortunately it
works fine here.
OK I can reproduce it in 32-bit now. Let's see what happens...
Willy
On Fri, Jan 17, 2014 at 11:03:51AM +0100, Willy Tarreau wrote:
On Fri, Jan 17, 2014 at 10:47:01AM +0100, Willy Tarreau wrote:
So I might have broken something in the way to count the try value,
ending up with zero being selected and nothing done. Unfortunately it
works fine here.
OK I
Le 17/01/2014 11:14, Willy Tarreau a écrit :
On Fri, Jan 17, 2014 at 11:03:51AM +0100, Willy Tarreau wrote:
On Fri, Jan 17, 2014 at 10:47:01AM +0100, Willy Tarreau wrote:
So I might have broken something in the way to count the try value,
ending up with zero being selected and nothing done.
Confirmed on my side as well. No segfault, and no spinning CPU with the
latest patch.
thanks!
Steve Ruiz
Manager - Hosting Operations
Mirth
ste...@mirth.com ste...@mirthcorp.com
On Fri, Jan 17, 2014 at 10:25 AM, Cyril Bonté cyril.bo...@free.fr wrote:
Le 17/01/2014 11:14, Willy Tarreau a
Hi Willy,
Le 15/01/2014 01:08, Willy Tarreau a écrit :
On Tue, Jan 14, 2014 at 12:25:37PM -0800, Steve Ruiz wrote:
Patched and confirmed in our environment that this is now working / seems
to have fixed the issue. Thanks!
Great, many thanks to you both guys. We've got rid of another pretty
Cyril is correct - I simply waited for a segfault, but didn't actually test
through the load balancer. I'm using SSL on haproxy, and yes, when I try to
hit a web page behind haproxy, CPU spins at 100% for a good while.
Steve Ruiz
Manager - Hosting Operations
Mirth
ste...@mirth.com
Hi Cyril,
On Tue, Jan 14, 2014 at 08:23:00AM +0100, Willy Tarreau wrote:
Hey, excellent catch! You're absolutely right. I'm totally ashamed
for not having found it while reading the code. I was searching for
a place where a wrong computation could lead to something larger
than the buffer and
OK here's a proposed fix which addresses the API issue for both
raw_sock and ssl_sock.
Steve, it would be nice if you could give it a try just to confirm
I didn't miss anything.
Thanks,
Willy
From 3e499a6da1ca070f23083c874aa48895f00d0d6f Mon Sep 17 00:00:00 2001
From: Willy Tarreau w...@1wt.eu
Hi again Willy,
Le 14/01/2014 12:22, Willy Tarreau a écrit :
OK here's a proposed fix which addresses the API issue for both
raw_sock and ssl_sock.
Steve, it would be nice if you could give it a try just to confirm
I didn't miss anything.
OK, from my side, now I'm on the laptop where I can
Willy, have you validated this version in our lab as well
Baptiste
Le 14 janv. 2014 19:21, Cyril Bonté cyril.bo...@free.fr a écrit :
Hi again Willy,
Le 14/01/2014 12:22, Willy Tarreau a écrit :
OK here's a proposed fix which addresses the API issue for both
raw_sock and ssl_sock.
Steve,
Patched and confirmed in our environment that this is now working / seems
to have fixed the issue. Thanks!
Steve Ruiz
On Tue, Jan 14, 2014 at 3:22 AM, Willy Tarreau w...@1wt.eu wrote:
OK here's a proposed fix which addresses the API issue for both
raw_sock and ssl_sock.
Steve, it would be
On Tue, Jan 14, 2014 at 12:25:37PM -0800, Steve Ruiz wrote:
Patched and confirmed in our environment that this is now working / seems
to have fixed the issue. Thanks!
Great, many thanks to you both guys. We've got rid of another pretty
old bug, these are the ones that make me the happiest once
Hi again Steve,
On Mon, Jan 13, 2014 at 08:44:08AM +0100, Willy Tarreau wrote:
Hi Steve,
On Fri, Jan 10, 2014 at 02:16:48PM -0800, Steve Ruiz wrote:
I'm experimenting with haproxy on a centos6 VM here. I found that when I
specified a health check page (option httpchk GET /url), and that
Willy,
Can you take me off of this list?
Unsubscribing doesn't work. I have no idea why. I've tried many times.
The last time I tried, I got back a message that gmail was identified
as a spammer.
Here is a sample of my unsubscribe message:
- snip
MIME-Version: 1.0
Received: by
Hi Tim,
On Mon, Jan 13, 2014 at 12:25:30PM -0500, Tim Prepscius wrote:
Willy,
Can you take me off of this list?
done!
Unsubscribing doesn't work. I have no idea why. I've tried many times.
The last time I tried, I got back a message that gmail was identified
as a spammer.
This is the
On Mon, Jan 13, 2014 at 10:10:45AM -0800, Steve Ruiz wrote:
sure thing, trace attached. Looking at the page returned, the only strange
thing I can see is that there are extremely long lines in the response -
I'm guessing on the order of 100k / line.
I also tried this but failed to see the
There's something excellent in your trace :
09:52:29.759117 sendto(1, GET /cp/testcheck.php HTTP/1.0\r\n..., 34,
MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 34
09:52:29.759357 epoll_ctl(0, EPOLL_CTL_MOD, 1, {EPOLLIN|0x2000, {u32=1,
u64=1}}) = 0
09:52:29.759487 gettimeofday({1389635549, 759527}, NULL)
Hi Willy,
Le 13/01/2014 19:19, Willy Tarreau a écrit :
There's something excellent in your trace :
09:52:29.759117 sendto(1, GET /cp/testcheck.php HTTP/1.0\r\n..., 34,
MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 34
09:52:29.759357 epoll_ctl(0, EPOLL_CTL_MOD, 1, {EPOLLIN|0x2000, {u32=1,
u64=1}}) =
Hi again Willy,
Le 14/01/2014 00:51, Cyril Bonté a écrit :
I don't know if this is of any help because I don't have enough details
yet, but I jut reproduced segfaults while playing with the configuration
provided by Steve.
To reproduce it on my laptop, it's quite easy : generate a lot of
Hi Cyril!
On Tue, Jan 14, 2014 at 02:51:41AM +0100, Cyril Bonté wrote:
Le 14/01/2014 00:51, Cyril Bonté a écrit :
Well, I couldn't leave my debug session in its current state.
I know what it's like when you go to bed an cannot sleep with eyes
wide open thinking about your last gdb output :-)
Hi Steve,
On Fri, Jan 10, 2014 at 02:16:48PM -0800, Steve Ruiz wrote:
I'm experimenting with haproxy on a centos6 VM here. I found that when I
specified a health check page (option httpchk GET /url), and that page
didn't exist, we have a large 404 page returned, and that causes haproxy to
Hi Steve,
Could you give a try to the tcp-check and tell us if your have the same issue.
In your backend, turn your httpchk related directives into:
option tcp-check
tcp-check send GET\ /cp/testcheck.html\ HTTP/1.0\r\n
tcp-check send \r\n
tcp-check expect string good
Baptiste
On Fri,
Made those changes, and it seems to be working properly, no segfault yet
after ~2 minutes of checks. Thanks!
Steve Ruiz
Manager - Hosting Operations
Mirth
ste...@mirth.com ste...@mirthcorp.com
On Fri, Jan 10, 2014 at 3:06 PM, Baptiste bed...@gmail.com wrote:
Hi Steve,
Could you give a try
Well, let say this is a workaround...
We'll definitively have to fix the bug ;)
Baptiste
On Sat, Jan 11, 2014 at 12:24 AM, Steve Ruiz ste...@mirth.com wrote:
Made those changes, and it seems to be working properly, no segfault yet
after ~2 minutes of checks. Thanks!
Steve Ruiz
Manager -
Thanks for the workaround + super fast response, and glad to help :).
Steve Ruiz
Manager - Hosting Operations
Mirth
ste...@mirth.com ste...@mirthcorp.com
On Fri, Jan 10, 2014 at 3:53 PM, Baptiste bed...@gmail.com wrote:
Well, let say this is a workaround...
We'll definitively have to fix the
26 matches
Mail list logo
