[syslog-ng] Reliability of Remote logging via TCP/Syslog-NG

[Balazs Scheidler]

On Wed, 2005-06-15 at 16:45 +0200, Olaf Hoyer wrote:
> On Wed, 15 Jun 2005, Balazs Scheidler wrote:

> 
> Hi!
> 
> When I read that correctly, this means that on the client machine a 
> single line of data is thrown away, before it will reach the network 
> interface?

Yes, exactly. syslog-ng issues a write() call, the kernel reports no
problems, thus syslog-ng happily proceeds. Then on the next write()
call, the kernel reports EPIPE as it should have on the first occasion.

> I am also doing some syslog setup, where some embedded machines (running 
> syslog-ng 1.5.17) will log to a central machine, also running syslog-ng 
> 1.6.x, and I wonder, that, wenn on the client machine there is no data 
> waiting, what happens to the first line arriving, when the connection is 
> up again before this line arrives? I assume it shall be transmitted 
> unharmed, or is there anything to worry about?

On the connection I mean the TCP connection and not IP connectivity. If
the TCP connection breaks for whatever reason (RST, IP outage,
anything), the contents of the kernel's socket buffer is lost (e.g. the
data syslog-ng has assumed to be sent). This is at least one message, as
the kernel does not indicate write failure on the first write after the
connection was broken.

A simple solution is to "watch" for broken TCP connections by poll()
-ing them for reading (where EOF is guaranteed to happen immediately
after the TCP connection is broken). This is implemented in 1.9.x.

The real solution would be to revamp syslog over TCP, or use some of the
newly designed syslog protocols (over BEEP, but that's another matter).
The point is to have some kind of application layer acknowledgement of
messages which would ensure that a given message was properly received
by the peer and not lost in the socket buffers. This way, only messages
already acknowledged by the peer would be discarded.

-- 
Bazsi