Dear Bazsi, Brad Arlt schrieb:
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.
statistics are a very good idea and for many syslog-ng users its important to know as most as possible about messages dropped (for which destination, etc.), messages transfered by source ond/or destination and something more. I think the discussions about possible log destinations hasn't the real impact in this context. as you say its important that we prevent the daemon from stucks in-active with its internal statistics stuff. the real problem here is, to implement the output method of the stat. informations. but answer the following question: "is it really mandatory to realize a continuous output of statistical informations?" I think not. decide to which logging destination the stats should be send. I think the internal() log source is a better choice than brad's "oh shit!" file, because we keep save the flexibility of syslog-ng's rule-based flow control. but a separate log is ok. but don't send the stats continuously to internal(). do this e.g. at midnight for the last 24h. realize a command line switch to disable this feature. if 24h is to long, implement a signal handler for e.g. SIGUSR1|2 that activates the stats output. so its possible for each user to decide the time on which he likes stats by sending a SIGUSR? to the daemon.
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).
thx. for your help best regards -- ASL