Hi Marc-Antoine,
On Tue, Feb 12, 2013 at 10:53:54AM +0100, Marc-Antoine Perennou wrote:
> +systemd/haproxy.service: contrib/systemd/haproxy.service.in
> + mkdir -p systemd
> + sed -e 's:@SBINDIR@:'$(strip $(SBINDIR))':' $< > $@
> +
I'm a bit worried with this one, because it will create a
Hi Lukas,
On Wed, Feb 13, 2013 at 01:03:40AM +0100, Lukas Tribus wrote:
>
> Hi Willy,
>
> I tried to enable tfo on the bind line today, however, it failed even on
> recent kernels for me.
>
> At first it was failing with:
> [ALERT] 042/223418 (1141) : parsing [haproxy.cfg:14] : 'bind *:1234' un
On 13 February 2013 00:11, Daniel Schultze wrote:
> Willy, devs,
>
> I am wondering if systemd support would be a feature you're interested in
> for haproxy. I have been using haproxy on Fedora 17 and noticed the lack of
> support and would like to contribute a systemd service file to support
> Fe
Hi Willy,
I tried to enable tfo on the bind line today, however, it failed even on
recent kernels for me.
At first it was failing with:
[ALERT] 042/223418 (1141) : parsing [haproxy.cfg:14] : 'bind *:1234' unknown
keyword 'tfo'. Registered keywords :
Since this pointed to a trivial parser issue
Thanks.
Sorry for the mangled patch, I figured the webmailer isn't the best way to send
patches ... getting familiar with git is still on my todo-list however.
Lukas
> Date: Tue, 12 Feb 2013 23:43:30 +0100
> From: w...@1wt.eu
> To: luky...@hotmail.co
On Tue, Feb 12, 2013 at 10:13:19PM +0100, Lukas Tribus wrote:
>
> The current documentation of the bind option "interface" can be misleading
> (as seen on the ML recently).
(...)
Patch applied, thanks Lukas.
BTW, you should be careful, your mailer has mangled the patch and I
had to apply it by h
The current documentation of the bind option "interface" can be misleading
(as seen on the ML recently).
This patch tries to address misunderstandings by :
- avoiding the words listen or bind in the behavior description, using
"restrict to interface" instead
- using a different sentence
On Tue, Feb 12, 2013 at 07:42:08AM -0500, David Coulson wrote:
>
> On 2/12/13 7:38 AM, Cornelius Riemenschneider wrote:
> >RE: Problems with 1.5-dev17 and bind to interface
> >
> >Ah okay, I expected bind :*12340 interface eth1 to listen to traffic
> >coming to the interface, not to bind to al ip
HAProxy community is great
On Tue, Feb 12, 2013 at 8:29 PM, Willy Tarreau wrote:
> Just a quick update on the subject for people following this thread.
>
> Today with Finn Arne's help I could finally spot the issue which is
> triggered by the use of "observe layer7". This affects all 1.5-de
Just a quick update on the subject for people following this thread.
Today with Finn Arne's help I could finally spot the issue which is
triggered by the use of "observe layer7". This affects all 1.5-dev
versions past 1.5-dev12. After being tested the whole afternoon, the
fix was pushed upstream a
> Ah okay, I expected bind :*12340 interface eth1 to listen to traffic
> coming to the interface, not to bind to al ips which are bound to the
> interface at the moment of starting haproxy. If that's really the case,
> the documentation of bind interface could be improved.
I think you misunderst
On Tue, Feb 12, 2013 at 12:38 PM, Cornelius Riemenschneider
wrote:
> **
>
> Ah okay, I expected bind :*12340 interface eth1 to listen to traffic
> coming to the interface, not to bind to al ips which are bound to the
> interface at the moment of starting haproxy. If that's really the case, the
> d
On 2/12/13 7:38 AM, Cornelius Riemenschneider wrote:
RE: Problems with 1.5-dev17 and bind to interface
Ah okay, I expected bind :*12340 interface eth1 to listen to traffic
coming to the interface, not to bind to al ips which are bound to the
interface at the moment of starting haproxy. If tha
Ah okay, I expected bind :*12340 interface eth1 to listen to traffic coming to
the interface, not to bind to al ips which are bound to the interface at the
moment of starting haproxy. If that's really the case, the documentation of
bind interface could be improved.
Cornelius Riemenschneider
--
On 2/12/13 7:32 AM, Cornelius Riemenschneider wrote:
The server is configured to listen to all traffic on eth1 to a specific port
(12340), so either traffic sent to its normal internal ip adress or to its VIP
address, in case keepalived assigned it to us will result in haproxy receiving
traff
Hello,
I don't see how my solution is broken by design. I see that
net.ipv4.ip_nonlocal_bind=1 is superior and widely used, so i'm using that
happily. But i still believe there's a bug or misdocumentation somewhere in
bind interface. Consider my setup: eth0: external ip address, used to ssh in
"haproxy+unsubscribe@..."
Monitored cpu usage per second now:
11:52:38 AM 28508223.001.000.004.00 4 haproxy
11:52:39 AM 2850822 43.00 58.000.00 101.00 4 haproxy
11:52:40 AM 2850822 42.00 57.000.00 99.00 4 haproxy
At 11:52:39 the following happened:
2013-02-12T11:52:
On Tue, Feb 12, 2013 at 12:10:00PM +0100, Finn Arne Gangstad wrote:
> New haproxy running, may take some hours before it happens again. I'll
> see if I can get it nailed down to the second it happens. In the
> meantime, I did some digging into the CPU logs, the last incident
> happened at 00:02:00
New haproxy running, may take some hours before it happens again. I'll
see if I can get it nailed down to the second it happens. In the
meantime, I did some digging into the CPU logs, the last incident
happened at 00:02:00 +- 15 seconds, here is the log output from
haproxy around that time (excludi
On Tue, Feb 12, 2013 at 11:16:32AM +0100, Willy Tarreau wrote:
> Just to confirm it doesn't come from commit 1c07b0755, could you please
> try to apply the attached patch which reverts it ?
As usual I forgot to attach the patch. Here it is.
Willy
diff --git a/src/ev_epoll.c b/src/ev_epoll.c
inde
Hi Finn Arne,
On Tue, Feb 12, 2013 at 11:07:55AM +0100, Finn Arne Gangstad wrote:
> I have a server running v1.5-dev17-17-gcf181c9 which "reliably" (after
> a few hours) gets into a state where it spends 100% in epoll. It still
> works as it should, but calls epoll all the time. I'm pretty sure it
I have a server running v1.5-dev17-17-gcf181c9 which "reliably" (after
a few hours) gets into a state where it spends 100% in epoll. It still
works as it should, but calls epoll all the time. I'm pretty sure it
started happening after i adjusted some timeouts and added "observe
layer7".
strace loo
Signed-off-by: Marc-Antoine Perennou
---
.gitignore | 1 +
Makefile | 8 ++--
contrib/systemd/haproxy.service.in | 11 +++
3 files changed, 18 insertions(+), 2 deletions(-)
create mode 100644 contrib/systemd/haproxy.service.in
diff
Currently, to reload haproxy configuration, you have to use "-sf".
There is a problem with this way of doing things. First of all, in the systemd
world,
reload commands should be "oneshot" ones, which means they should not be the
new main
process but rather a tool which makes a call to it and th
This patch adds a new option "-Ds" which is exactly like "-D", but instead of
forking n times to get n jobs running and then exiting, prefers to wait for all
the
children it just created. With this done, haproxy becomes more
systemd-compliant,
without changing anything for other systems.
Signed-
26 matches
Mail list logo
