[syslog-ng] Silence syslog-ng upon connection reopening?

[Wolfram Schlich]

* Balazs Scheidler <bazsi at balabit.hu> [2006-11-24 09:23]:
> On Thu, 2006-11-23 at 20:16 +0100, Wolfram Schlich wrote:
> > * Balazs Scheidler <bazsi at balabit.hu> [2006-11-23 19:41]:
> > > On Thu, 2006-11-23 at 19:35 +0100, Wolfram Schlich wrote:
> > > > Hi,
> > > > 
> > > > is it possible to silence syslog-ng running on a log client
> > > > when it reopens a TCP connection to the syslog-ng log server?
> > > > 
> > > > For example, when you restart syslog-ng on the server due
> > > > to some configuration change or whatever other reason, syslog-ng on
> > > > the log client logs this to syslog.err:
> > > > 
> > > > 	syslog-ng[13214]: io.c: do_write: write() failed, EOF detected
> > > > 	syslog-ng[13214]: pkt_buffer::do_flush(): Error flushing data
> > > > 	syslog-ng[13214]: Connection broken to AF_INET(log-server:514), reopening in 10 seconds       
> > > > 
> > > > Can I make syslog-ng NOT log those messages until, let's say,
> > > > the reopening failed at least N times?
> > > > [...]
> > > 
> > > It is not currently possible, and I don't have a good solution right
> > > now.
> > 
> > What about logging with severity warn instead of err?
> > That would solve the problem for me (I do only get notified
> > immediately about err, crit and emerg).
> > 
> > Can it be done without "breaking" other cases where such
> > messages would occur and err would be the most suitable
> > severity?
> 
> Sorry, but no, syslog-ng uses only four levels internally:
> 
> MSG_ERROR: LOG_ERR; (error messages)
> MSG_FATAL: LOG_CRIT; (fatal errors that cause syslog-ng to exit abnormally)
> MSG_DEBUG: LOG_DEBUG; (debug messages, enabled with -d)
> MSG_VERBOSE: LOG_NOTICE (verbose mode messages, enabled with -v)
> MSG_NOTICE: LOG_NOTICE; (informational messages, always enabled)
> 
> Changing error severities would affect all messages globally. I'm
> reluctant to change the error messages associated with connection errors
> anything less than MSG_ERROR.

Ok. Then what about a solution like the one I mentioned in the first
place -- only logging such messages if connection reopening failed
at least N (configurable number of) times?

> Any in addition, I'm very reluctant to change the 1.6.x codebase, now as
> 2.0.0 was released. :)

Oh, well, switching to 2.x for the log clients would not be a problem :)

Best regards
-- 
Wolfram Schlich