[syslog-ng] bug report

[Balazs Scheidler]

On Thu, 2006-09-21 at 14:29 -0500, Matt Zagrabelny wrote:
> On Thu, 2006-09-21 at 20:53 +0200, Sandor Geller wrote:
> > Matt Zagrabelny wrote:
> > > does anyone on the list know the preferred way of submitting bug reports
> > > to the developers?
> > 
> > Why don't you send your report to the list? 
> 
> just wanted to make sure the bugreport wouldnt fall on deaf ears. ;)
> 
> the problem has to do with using the program() destination driver
> dropping syslog entries, or at least the program not receiving them. it
> may very well be a problem with the program i am using, but i thought i
> would pass it on to the experts.
> 
> what happens is that when the program() is executing a remote command,
> for example via ssh, any successive input on STDIN is dropped or not
> received or not sent or something. thus to test this phenomenon, the
> program() must get more than one line at a time (or perhaps, at least a
> second line before the remote program is done executing). exact timing
> of the failure hasnt been investigated yet. the test below uses the auth
> facilities because establishing an ssh connection sends more than one
> message to syslog.

syslog-ng 1.6.x does not ensure that input and output flows are
controlled, e.g. it might happen that more messages enter syslog-ng than
it is able to send out.

If the internal log message fifo overflows (you can control its size
using log_fifo_size) syslog-ng will start dropping messages, and it
reports such cases in the "STATS" message it generates every once in a
while.

Syslog-ng 2.0.x has a solution for this problem, it can stop reading
input messages if the output queues are full. This can be enabled on a
per-log-statement basis, using the "flow-control" flag, like this:

log { source(src); destination(dst); flags(flow-control); };

This way, if the input channels are flow controlled (e.g. connection
oriented sockets), syslog-ng will be able to block applications a bit
while its output queues are flushed.

If a program destination is slow for a little while (e.g. during
startup), the output queue will fill up quickly. In this case the only
possibility is to stop the application. If the destination remains slow,
the slow-down propagates back to the application, and the service
becomes slower as a whole.

Hope this explanation helps,

-- 
Bazsi