Bind Queries log file format
muks at isc.org
Wed Jan 25 13:51:00 UTC 2017
On Wed, Jan 25, 2017 at 08:37:45AM -0500, Alan Clegg wrote:
> On 1/25/17 7:44 AM, Steven Carr wrote:
> > On 25 January 2017 at 10:59, Tony Finch <dot at dotat.at> wrote:
> >> It's the address in memory of the data structure representing the client.
> >> It is mentioned in the CHANGES file (#4471) and in the release notes - see
> >> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c4b7db49326be650fa95a7ede6e066bbe1268561
> >> though the pointer field first turned up in
> >> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=a26a62cef2adba0520c5955d740fc75fa7f2c7f5
> > Question back to the BIND team... why? what is the purpose of having
> > this value exposed in query logs? what exactly is it adding? If it was
> > a debug log then I can understand the need to have the memory address
> > exposed, but for the "regular" user what is the use case?
> BIND is always in debug mode, even when it's not in debug mode.
> I find this addition to the log to be annoying and useless in 99% of
> actual end-user use cases.
Rememeber that not only users, but even us developers have to look at
your logs when you send them to us.
When things are fine, the sun is shining, hay is growing.. all's fine,
and the fields in the log format that a user wants are sufficient.
When one out of numerous deployments of BIND reports a crash, and we're
not able to reproduce it, all we have is the effects that the reporter
can provide us. named is asynchronous software with numerous concurrent
wheels chugging, with some shared datastructures and non-shared request
specific structures. When things go bad, they show up as bad sometimes
a long time after the fact. If we are not able to reproduce it, looking
at logs and attempting to reconstruct what happened is like looking for
a needle in a haystack. In such cases, we find these bits of extra
information useful. Users may not like an extra field, but please bear
with us because it is helpful when things go bad.
This specific client pointer was useful in debugging such an issue and
that's why it was permanently added to the log.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the bind-users