[Fwd: [syslog-ng]Full pipe as destination]
Peter Draexler schrieb:
Dear Bazsi, thank you for your info. This should help. Nevertheless, does syslog-ng log somewhere if it discards events or do you know another way to check this? This would be important to adapt log_fifo_size. Currently we only observe by chance that we lose information. Best regards Peter
Balazs Scheidler schrieb:
On Tue, Aug 14, 2001 at 08:45:35AM +0200, Peter Draexler wrote:
Hi,
We are using syslog-ng on our logserver with multifunctional logforwarding. As a special type of destination we are using pipes as a special interface to commercial applications.
Here is our question: What happens with the log events, if the pipe becomes temp. unavailable (e.g. the reading end is dead or the pipe is full)?
IMHO you have to open() the pipe nonblocking, to avoid your syslog stucks in-active, in the case one destination is broken. I think this is true. Correct?
it's true.
What happens with your internal log buffers, if write() returns -1 and errno set to EAGAIN? You implement an internal buffering/queue and try to write the outstanding log events some times later or you simply discard the buffers as long as one destination is unreachable?
messages are queued up to the value of log_fifo_size, which IIRC can be set on a per-destination basis. if the fifo is full, messages are discarded.
A Hint for syslog-ng.1.5.8 on Solaris 8: $DATE in destination templates returns nothing. But $FULL|ISODATE works fine.
this seems to be fixed in my CVS tree, though it's not yet released.
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
-- Dr. Peter Dräxler mediaWays GmbH Hülshorstweg 30 33415 Verl Tel. +49-5246-80-1888 Fax +49-5246-80-2888 peter.draexler@mediaways.net ------------------------------
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
On Tue, Aug 21, 2001 at 01:26:27PM +0200, Peter Draexler wrote:
Peter Draexler schrieb:
Dear Bazsi, thank you for your info. This should help. Nevertheless, does syslog-ng log somewhere if it discards events or do you know another way to check this? This would be important to adapt log_fifo_size. Currently we only observe by chance that we lose information.
logs are silently dropped in this case. I was thinking of implementing some kind of automatic statistics message to report log losses, but that would race against normal log traffic. do you have a better idea. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Tue, Aug 21, 2001 at 02:16:09PM +0200, Balazs Scheidler wrote:
On Tue, Aug 21, 2001 at 01:26:27PM +0200, Peter Draexler wrote:
Peter Draexler schrieb:
Dear Bazsi, thank you for your info. This should help. Nevertheless, does syslog-ng log somewhere if it discards events or do you know another way to check this? This would be important to adapt log_fifo_size. Currently we only observe by chance that we lose information.
logs are silently dropped in this case. I was thinking of implementing some kind of automatic statistics message to report log losses, but that would race against normal log traffic. do you have a better idea.
A single message saying "log queue full" written to the syslog facilty at emerg would due it. And rather than compete have it win the race always. Since we are already losing messages, it is more important that we know we are losing messages than to know what messages have been lost (if that makes sense). One could also have a seperate "oh shit!" log file that only gets written to by syslog-ng internals and not through standard mechanisms. A non-blocking write(2) could be used to ensure that these messages didn't impeed on other logging (much). The only other thing I can think of is a message to the console (/dev/console or /dev/sysmsg, these may be Solaris isms though :) to force the message to appear on the console without going through the normal syslog methods (or maybe that is the normal syslog method). This isn't a terribly great solution, but at least one could say "Hey! That doesn't look right" on the daily stroll through the machine room. Also, an "everything is OK" error message when the queue fixes itself would be nice to see, but perhaps not a terribly good idea. The idea was to see when trouble started and when it stopped. Barring anything better, this information would be very handy in a forensic situation. ---------------------------------------------------------------------------- __o Bradley Arlt Email: arlt@cpsc.ucalgary.ca o__ _ \<_ WWW: www.acs.ucalgary.ca/~bdarlt _>/ _ (_)/(_) -Eat well, sleep peacefully, drink lots, and ride like hell. (_)\(_)
participants (3)
-
Balazs Scheidler
-
Brad Arlt
-
Peter Draexler