[syslog-ng]Full pipe as destination

[Andreas Schulze]

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