On Fri, Aug 30, 2013 at 02:43:03PM +0200, William Lallemand wrote:
> On Thu, Aug 29, 2013 at 10:50:09PM +0200, Lukas Tribus wrote:
> > The behavior also depends on the syslog facility; I used "syslog" in my
> > tests.
> >
> >
> > With the current git tree I see the following behavior:
> > ntp an
> Hello Lukas,
>
> Thanks for your analyze, the bug was indeed caused by the number of digits in
> the facility.
>
> Here's a patch with the real size to send :)
Thanks, I confirm it fixes the problem.
Regards,
Lukas
On Thu, Aug 29, 2013 at 10:50:09PM +0200, Lukas Tribus wrote:
> The behavior also depends on the syslog facility; I used "syslog" in my tests.
>
>
> With the current git tree I see the following behavior:
> ntp and local7: syslog ends with \n <-- correct behavior!
> ftp and user: syslog ends with
Hi William,
(apologies for the high volume in this thread)
> haproxy 1.4 and pre 2a4a44f0f9f behavior (expected):
> every syslog message ends with \n
>
> post 2a4a44f0f9f (REORG: log: split send_log function) behavior:
> every syslog message ends with \n + 1 random character
>
> post bfb099c3b3f
Hi William,
sorry, there is another commit involved here. This is what I see:
haproxy 1.4 and pre 2a4a44f0f9f behavior (expected):
every syslog message ends with \n
post 2a4a44f0f9f (REORG: log: split send_log function) behavior:
every syslog message ends with \n + 1 random character
post bfb0
Hi William,
> I can't reproduce the bug, how did you compile HAProxy?
> What is your configuration file?
I've trimmed this down to a very basic setup:
$ make TARGET=linux26 CPU=native
$ ./haproxy -vv
HA-Proxy version 1.5-dev19-55 2013/08/13
Copyright 2000-2013 Willy Tarreau
Build
On Thu, Aug 22, 2013 at 10:18:46AM +0200, Lukas Tribus wrote:
> > Is this happen randomly or can you pin point this to specifc requests, maybe
> > errors/timeouts? How can we reproduce this?
>
> Nevermind, its easily reproducible (just generate some syslog messages).
>
> The whole thing seems ran
> Is this happen randomly or can you pin point this to specifc requests, maybe
> errors/timeouts? How can we reproduce this?
Nevermind, its easily reproducible (just generate some syslog messages).
The whole thing seems random: most of the times, the syslog msg ends
with \n\0\0, other times with
Hi Sam!
> It appears that the syslog packets generated by 1.5dev19 do not always
> end in a newline. They appear to end in a newline, followed by two bytes
> of the last syslog buffer.
Is this happen randomly or can you pin point this to specifc requests, maybe
errors/timeouts? How can we repro
Hi,
Here at archive.org we are happy users of haproxy for many things.
I recently built and experimented with 1.5-dev19.
I noticed an oddity.
We use the syslog logging feature of haproxy. It appears that the syslog
packets generated by 1.5dev19 do
not always end in a newline. They appear to end
10 matches
Mail list logo
