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 and local7:
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 \n + 2
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 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 random:
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 w...@1wt.eu
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
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 bfb099c3b3f1
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
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
9 matches
Mail list logo
