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