Bind Queries log file format

[MURTARI, JOHN]

> We may move it to the end of the log message (bugs ticket #44606 has
> been created for looking at it). Maybe its location was poor.. please
> can everyone who participated in this thread say whether having it at
> the end will be ok?

It's really only for code debug.  I'd say give the admin a means via rndc/config
to turn it on 'debug' if needed.  That also allows you to add anything else you might
like in the future.
John


-----Original Message-----

From: Mukund Sivaraman <muks at isc.org>
To: Alan Clegg <alan at clegg.com>
Cc: bind-users at lists.isc.org
Subject: Re: Bind Queries log file format
Message-ID: <20170203164526.GA6221 at jurassic>
Content-Type: text/plain; charset="us-ascii"

On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote:
> On 2/3/17 8:01 AM, Mukund Sivaraman wrote:
> 
> > We have the debug log level, but consider the case when an operator has
> > a non-deterministic or rare crash that isn't reproducible because the
> > operator has no information about what caused it. All we have is the
> > config, log that was already generated before the crash and perhaps a
> > backtrace and core to deduce the steps leading to the crash. It's not
> > possible to re-run that scenario with debug logging.
> > 
> > I'll create a ticket to put the client pointer at the end if that'll
> > help, but note that the syntax in 9.10 was not consistent either. 9.10
> > would log the client pointer when the client object didn't have a valid
> > peer.
> 
> Adding code to allow enabling or disabling this output on the fly would
> work MUCH better (as an example, see "rndc querylog"/ options "querylog
> [on | off ]").
> 
> Adding a "well, we needed this one time" value to the middle of a
> long-standardized log file does no customer any good and inconveniences
> everyone.
> 
> You own the code and can do whatever you want to, but I'd recommend
> making the default log message what it was prior to 9.10 and adding
> additional fields via pre-configuration and "rndc".

We may move it to the end of the log message (bugs ticket #44606 has
been created for looking at it). Maybe its location was poor.. please
can everyone who participated in this thread say whether having it at
the end will be ok?

The query log is getting more fields at the end of it such as
CLIENT-SUBNET logging.

Making it a configurable option misses the reason it is the way it is -
please see the first paragraph quoted above.

This seems to be a case where having it is inconvenient, and not having
it is inconvenient.

		Mukund