=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: Apollon Oikonomopoulos apoi
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 patches
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 build
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 -lssl
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,
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
Add a man section to every system call reference, giving users pointers to the
respective manpages.
Signed-off-by: Apollon Oikonomopoulos apoi...@gmail.com
---
doc/haproxy.1 | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index
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 apoi...@gmail.com
---
doc/haproxy.1 |5 ++---
1 file changed, 2 insertions
Document -L, -v(v), -C, -dS and -dM, as they were missing from the manpage.
Signed-off-by: Apollon Oikonomopoulos apoi...@gmail.com
---
doc/haproxy.1 | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index 48717ad
These options are no longer supported since 1.3, so remove them from the
manpage.
Signed-off-by: Apollon Oikonomopoulos apoi...@gmail.com
---
doc/haproxy.1 | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/doc/haproxy.1 b/doc/haproxy.1
index 85244af..c479cc8
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
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 with 8.31) includes:
libS=
if test
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 however is
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
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 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
version,
(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 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
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 ?? ()
(gdb)
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 anymore,
so please
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,
Apollon
Apollon
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
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
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
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
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 Debian
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 my high throne
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 (--configure):
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 running
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 you
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
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 includes the wrapper, the master
process
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 at 03:14:41PM +0300, Apollon Oikonomopoulos wrote:
By default
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
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
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, 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
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 wrot
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
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)
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
41 matches
Mail list logo
