On 17:30 Thu 12 Oct , William Lallemand wrote:
> On Thu, Oct 12, 2017 at 05:50:52PM +0300, Apollon Oikonomopoulos wrote:
> > Yes, there are. systemd will only perform a single operation on a
> > unit at a time, and will queue up the rest. When you inform systemd
> > th
On 16:17 Thu 12 Oct , William Lallemand wrote:
> Hi,
>
> On Thu, Oct 12, 2017 at 01:19:58PM +0300, Apollon Oikonomopoulos wrote:
> > The biggest issue here is that we are using a signal to trigger the
> > reload (which is a complex, non-atomic operation) and let things
Hi all,
On 22:01 Wed 04 Oct , Lukas Tribus wrote:
> Hello Moemen,
>
>
> Am 04.10.2017 um 19:21 schrieb Moemen MHEDHBI:
> >
> > I am wondering if this is actually an expected behaviour and if maybe
> > that restart/stop should just shutdown the process and its open connections.
> > I have mad
Hi Pavlos,
On 17:31 Fri 09 Dec , Pavlos Parissis wrote:
> On 09/12/2016 08:54 πμ, Apollon Oikonomopoulos wrote:
> > Hi Willy, Elias,
> >
> > On 08:33 Fri 09 Dec , Willy Tarreau wrote:
> >> On Thu, Dec 01, 2016 at 02:53:25PM +0100, Elias Abacioglu wrote:
Hi Willy, Elias,
On 08:33 Fri 09 Dec , Willy Tarreau wrote:
> On Thu, Dec 01, 2016 at 02:53:25PM +0100, Elias Abacioglu wrote:
> > # Should I use core 0 on each CPU for backends (proc 1+15) or should
> > I
> > use core 1(proc 2+16)?
>
> Backends are processed on the same CPU as the frontend
On 12:07 Wed 09 Nov , Willy Tarreau wrote:
> On Wed, Nov 09, 2016 at 11:44:41AM +0200, Apollon Oikonomopoulos wrote:
> > Thanks for this. Is it too much of a hassle to ask for a 1.6 backport?
>
> Given that it breaks support for older versions (0.9.8 at least), for
> now it
Hi Willy, Dirkjan,
On 21:12 Tue 08 Nov , Willy Tarreau wrote:
> Hi Dirkjan,
>
> I finally merged your patch after discussing with Emeric. He's fine with
> it as well.
Thanks for this. Is it too much of a hassle to ask for a 1.6 backport?
We currently have a release-critical bug in Debian fo
On 12:07 Thu 09 Oct , Willy Tarreau wrote:
> Anyway we're not there to discuss the benefits or defaults of systemd,
> some major distros have adopted it and now we have to work around its
> breakages so that users can continue to use their systems as if it was
> still a regular, manageable UNIX
On 11:44 Thu 09 Oct , Willy Tarreau wrote:
> On Thu, Oct 09, 2014 at 12:35:10PM +0300, Apollon Oikonomopoulos wrote:
> > Hi Willy,
> >
> > On 11:26 Thu 09 Oct , Willy Tarreau wrote:
> > > Hi Apollon,
> > >
> > > On Wed, Oct 08, 2014 a
Hi Willy,
On 11:26 Thu 09 Oct , Willy Tarreau wrote:
> Hi Apollon,
>
> On Wed, Oct 08, 2014 at 03:14:41PM +0300, Apollon Oikonomopoulos wrote:
> > By default systemd will send SIGTERM to all processes in the service's
> > control group. In our case, this includ
By default systemd will send SIGTERM to all processes in the service's
control group. In our case, this includes the wrapper, the master
process and all worker processes.
Since commit c54bdd2a the wrapper actually catches SIGTERM and survives
to see the master process getting killed by systemd and
Hi Willy,
On 19:18 Thu 02 Oct , Willy Tarreau wrote:
> So my question is : what do you think about the current maintenance
> release frequency ? Do you think we should release more often, which
> also means that some people might upgrade for no good reason, or get
> used to miss versions ? Do
Hi Willy,
On 19:28 Fri 25 Jul , Willy Tarreau wrote:
>
> Concerning the new features, no promises, but we know that we need to
> progress in the following areas :
>
> - multi-process : better synchronization of stats and health checks,
> and find a way to support peers in this mode. I'
Hi Kevin,
On 15:51 Wed 23 Jul , Kevin COUSIN wrote:
> Here is the reload command in the systemd unit file:
> ExecReload=/bin/bash -c "exec /usr/sbin/haproxy -D -f
> /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -sf $MAINPID"
This command will not work, because it will replace the already runni
On 11:14 Wed 04 Jun , Ghislain wrote:
> just in case, last update failed:
>
> Setting up haproxy (1.5~dev26-1~bpo70+1) ...
> Starting haproxy: haproxy/usr/sbin/haproxy already running.
> failed!
> invoke-rc.d: initscript haproxy, action "start" failed.
> dpkg: error processing haproxy (--conf
On 17:10 Fri 23 May , Ghislain wrote:
> Le 23/05/2014 15:23, Baptiste a écrit :
> >It is not provided by us (HAProxy.com) if this is what you mean.
> >
> >Baptiste
> >
> >
>
> yes that's what i meant. Thanks for both answer and thanks for the product,
> and the packages !
>
> In any case from
Hi Ghislain,
On 14:01 Fri 23 May , Ghislain wrote:
> hello there,
>
> Could you tell me if those packages comes from the haproxy team ? from the
> packages:
It depends on what you mean by the "haproxy team". They come from the
team that maintains the package in Debian itself, that means D
Hi all,
On 22:59 Wed 23 Apr , Willy Tarreau wrote:
> Hi again Markus,
>
> I've checked my own logs and found SSL handshake failures starting
> on April 8th, or the day after Heartbleed was disclosed, as can be
> seen below with the number of errors per day :
>
> # err date
> 2 Mar 27
Use HAProxy's exit status as the systemd wrapper's exit status instead
of always returning EXIT_SUCCESS, permitting the use of systemd's
`Restart = on-failure' logic.
---
src/haproxy-systemd-wrapper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/haproxy-systemd-wrapper.c
reliably
to systemd's journal than stdout.
- We also use systemd's support for prefixing messages with the log level to
differentiate between message severity.
- Finally, we propagate the exit status of HAProxy to systemd, instead of
always returning success.
Regards,
Apollo
Re-execute the systemd wrapper on SIGUSR2 and before reloading HAProxy,
making it possible to load a completely new version of HAProxy
(including a new version of the systemd wrapper) gracefully.
Since the wrapper accepts no command-line arguments of its own,
re-execution is signaled using the HAPR
Use standard error for logging messages, as it seems that this gets
messages to the systemd journal more reliably. Also use systemd's
support for specifying log levels via stderr to apply different levels
to messages.
---
src/haproxy-systemd-wrapper.c | 15 +--
1 file changed, 9 insert
On 12:30 Thu 17 Apr , Lukas Tribus wrote:
> Hi,
>
>
> >> Can you compile with CFLAGS="-g -O0" in the make command, to avoid that
> >> the compiler optimizes out to much and provide the gdb output of
> >> "backtrace full"?
> >
> > Strange, after a full cleanup and rebuild it doesn't segfault a
Hi Lukas,
On 12:09 Thu 17 Apr , Lukas Tribus wrote:
> Hi,
>
> > gdb shows:
> >
> > Program received signal SIGUSR1, User defined signal 1.
> > [WARNING] 106/123715 (18187) : Stopping frontend test in 0 ms.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x in
Hi all,
Current master segfaults during soft-stop with the following config:
global
log /dev/loglocal0
frontend test
mode http
bind 127.0.0.1:
bind ::1:
redirect prefix http://example.com
gdb shows:
Program received signal SIGUSR1, User defin
(Cc'ing the Debian maintainers as well)
Hi all,
On 19:28 Wed 16 Apr , Willy Tarreau wrote:
> On Wed, Apr 16, 2014 at 07:14:31PM +0300, pablo platt wrote:
> > An official Ubuntu dev repo will also make testing easier.
> > It's much easier to use a apt-get than building from source and figuring
Hi Jonathan,
On 22:27 Mon 14 Apr , Jonathan Matthews wrote:
> Hi all -
>
> I've been running 1.4 for a number of years, but am pondering moving
> some as-yet-unreleased apps to 1.5, for SSL and ACL-ish reasons.
>
> I'd like to ask how you, 1.5 sysadmins and devs, track the development
> vers
Hi Thierry,
On 21:31 Mon 14 Apr , Thierry FOURNIER wrote:
> Hi,
>
> Thanks for the bug repport, this is fixed in the current HAProxy version.
>
Tested and it works fine, thanks for the fix!
Apollon
Hi,
While experimenting with counters in a dual-stack setup, I noticed that
src_inc_gpc0 does not seem to work for IPv4 clients looked up against
type ipv6 stick-tables. The following configuration:
global
log 127.0.0.1local0
user haproxy
group haproxy
stats socket /var
Hi Willy,
On 07:57 Sun 06 Apr , Willy Tarreau wrote:
>
> In fact I intentionally made this choice because Apache does the same and
> wanted to ensure the least possible breakage by inserting haproxy in front
> of it (you can't imagine how users are picky when something does not work
> anymore
RFC 1945 (§4.1) defines an HTTP/0.9 request ("Simple-Request") as:
Simple-Request = "GET" SP Request-URI CRLF
HAProxy tries to automatically upgrade HTTP/0.9 requests to
to HTTP/1.0, by appending "HTTP/1.0" to the request and setting the
Request-URI to "/" if it was not present. The latter how
On 13:49 Mon 30 Sep , Apollon Oikonomopoulos wrote:
> Hi Vincent,
>
> On 12:19 Mon 30 Sep , Vincent Bernat wrote:
> > For me, pcre-config --libs does not use `-L`. Dunno why this is the
> > case for Apollon.
>
> My version of pcre-config (8.30, also tested wit
Hi Vincent,
On 12:19 Mon 30 Sep , Vincent Bernat wrote:
> For me, pcre-config --libs does not use `-L`. Dunno why this is the
> case for Apollon.
My version of pcre-config (8.30, also tested with 8.31) includes:
libS=
if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
libS=-L${pref
These options are no longer supported since 1.3, so remove them from the
manpage.
Signed-off-by: Apollon Oikonomopoulos
---
doc/haproxy.1 | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index 85244af..c479cc8 100644
--- a/doc
The manpage refers to haproxy-en.txt, which is obsolete. Update the reference
to point to configuration.txt, together with the location on Debian systems.
Also capitalize "Debian".
Signed-off-by: Apollon Oikonomopoulos
---
doc/haproxy.1 |5 ++---
1 file changed, 2 insert
Document -L, -v(v), -C, -dS and -dM, as they were missing from the manpage.
Signed-off-by: Apollon Oikonomopoulos
---
doc/haproxy.1 | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index 48717ad..0fb2538 100644
Add a man section to every system call reference, giving users pointers to the
respective manpages.
Signed-off-by: Apollon Oikonomopoulos
---
doc/haproxy.1 | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index 0fb2538..a2ac857
Hi,
The following set of patches updates the manpage, adding missing options,
removing obsolete options and fixing external references.
Regards,
Apollon
Apollon Oikonomopoulos (4):
DOC: add missing options to the manpage
DOC: add manpage references to all system calls
DOC: update manpage
Hi Willy,
On 18:30 Sun 29 Sep , Willy Tarreau wrote:
> That's problematic. The issue was created by the addition of
> pcre-config
> because some people could not build on their systems in the past. The whole
> mess started with the lib64 subdir that broke basically every software
> relying on
Hi all,
On 13:35 Sun 29 Sep , Willy Tarreau wrote:
> Yes, and I have fixed this two weeks ago. The problem is that the
> "ADDINC"
> and "ADDLIB" variables are not suited for passing single-component paths
> since they suffix everything. Look what it results in your build log :
>
> -lcrypt
Hi Julien,
On 10:35 Sat 28 Sep , Julien Vehent wrote:
> On 2013-09-27 21:17, Lukas Tribus wrote:
> >Try stable OpenSSL 1.0.1e, that should work.
>
> I did, and I get the exact same error.
> The problem happens on Debian Squeeze. My laptop on Fedora 19
> doesn't have the issue.
>
HAProxy's b
On 12:34 Mon 12 Aug , Willy Tarreau wrote:
> Hi Apollon,
>
> Unfortunately, this patch introduces a memory leak. Since the path
> variable is just a temporary one, better use alloca() instead in
> order to dynamically allocate on the stack.
Ooops, completely forgot to free(). Never submit pat
1.5%7Edev19-1&stamp=1372199388
The attached patch should fix this issue, by modifying the code in
question to use a dynamically allocated buffer while checking against
PATH_MAX if appropriate.
Regards,
Apollon
>From 865e8c1ed5bc8dfa61eff6c33e5b59b6a554db96 Mon Sep 17 00:00:00 2001
From: Ap
43 matches
Mail list logo