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