Hi Gabriele,
I assigned some time on this issue and fixed it. The wrapper's code was
simply wrong as the wait()'s status must not be passed directly to exit()
otherwise it truncates it. It's now OK, I've just merged the attached patch
that I'll backport to 1.6 and 1.5.
Thanks for reporting this
On 26 Oct, Willy Tarreau wrote:
> to think of it. Are you sure your version doesn't contain certain patches
> affecting the error return path, maybe just some local debugging patches
> that were forgotten ?
I'm only seeing this applied before creating the package
On Wed, Oct 26, 2016 at 11:53:08AM +0200, Gabriele Cerami wrote:
> On 22 Oct, Willy Tarreau wrote:
> > Hi Gabriele,
> >
> > On Tue, Oct 18, 2016 at 09:40:14PM +0200, Gabriele Cerami wrote:
> > > Hi,
> > >
> > > We're having a problem with version 1.5.14 of haproxy, packaged for
> > > CentOS 7,
On 22 Oct, Willy Tarreau wrote:
> Hi Gabriele,
>
> On Tue, Oct 18, 2016 at 09:40:14PM +0200, Gabriele Cerami wrote:
> > Hi,
> >
> > We're having a problem with version 1.5.14 of haproxy, packaged for
> > CentOS 7, but it seems even the code in master is affected.
> >
> > In situations where
Hi Gabriele,
On Tue, Oct 18, 2016 at 09:40:14PM +0200, Gabriele Cerami wrote:
> Hi,
>
> We're having a problem with version 1.5.14 of haproxy, packaged for
> CentOS 7, but it seems even the code in master is affected.
>
> In situations where bind is not possible (in our case, the address was
>
Hi,
We're having a problem with version 1.5.14 of haproxy, packaged for
CentOS 7, but it seems even the code in master is affected.
In situations where bind is not possible (in our case, the address was
already in use) tcp_connect_server returns with a status of 256
(ERR_ALERT). This value is
6 matches
Mail list logo