On Sun, 2006-10-29 at 17:19 +0000, Hari Sekhon wrote:
Are there any pitfalls that you can think of when doing this? I don't think this will risk filling up the bit bucket on the logserver since the logs are immediately sent on via udp, "spray and pray". If they don't get to my workstation for any reason, no harm done, it won't clog up the logserver.
I guess the root-tail will take a bit out of my workstation having to draw on the X background all the time but it's a fast machine.
I believe that it would block my local syslog-ng on my workstation if the root-tail were to stop reading from it. Which brings me to my next question:
Is it better to do
root-tail /var/log/logstream.pipe
or
root-tail - < /var/log/logstream.pipe
Since I'm not sure that the first will take the actual throughput away from the pipe to stop the logger from blocking on the sending side.
Also, this would require that the my X session not be closed otherwise the root-tail wouldn't be able to run to take away the logs from the other side of the pipe and the local logger would block again.
All feedback welcome.
Another possibility is by using the latest multicasting feature, send the logs to a multicast address, have your workstation joined to the multicast group, and use the packets sent there. If you are not joined, it could mean no traffic (if set up properly), if you are you receive messages. There's an example script in contrib that does the joining and receiving part, but it could be hacked to do what you are up to. On the other hand the setup you are proposiing should work as well, syslog-ng won't block if the reader of a pipe does not read messages. It will simply start dropping messages internally (which you can then see as DROPPED messages in the stats message) -- Bazsi