> On Feb 7, 2017, at 11:07 PM, Mark Andrews wrote:
>
>
> No, we have a field that has more information in it. Same field E ->
> E(version)
>
> 08-Feb-2017 15:15:44.532 client @0x7fc1c803c600 127.0.0.1#57982/key external
> (rock.dv.isc.org): view external: query:
In message <2c577494-613a-419c-82c4-402ba581c...@stonejongleux.com>, Larry
Stone writes:
> Ive been around long enough to remember when upward compatability was
> something that was expected. A program built to work with the current
> version of data (e.g. data records, log records, whatever) or
"I’ve been around long enough to remember when upward compatibility was
something that was expected."
Having been around since before even Unix, I must say I agree totally.
As I understand it, Linus does not take kindly to Linux Kernel changes
that break forward/upward compatibility (of the
I’ve been around long enough to remember when upward compatability was
something that was expected. A program built to work with the current version
of data (e.g. data records, log records, whatever) or even a shared library was
expected to be able to continue to work with all future versions
In message , Paul Roberts writes:
> I have to say I agree with the approach of putting this extra info into a sep
> arate file. I appreciate this could cause additional problems (disk utilisati
> on, extra I/O's,
. :-)
Thanks,
Paul
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
MURTARI, JOHN
Sent: 06 February 2017 17:05
To: bind-users@lists.isc.org
Subject: RE: Bind Queries log file format
[snip]
> The additional logging info is specifically for the unus
> From: Warren Kumari [mailto:war...@kumari.net]
> Customer: "My BIND went Boom! It's been running fine for many years,
> and then for no reason at all it went Boom. Here are my log files..."
> ISC: "Doh. Sorry. Unfortunately the log file doesn't have sufficient
> debug info. Can you please turn
Am 06.02.2017 um 14:25 schrieb Warren Kumari:
I suspect perhaps some of the thread got missed (or was unclear).
The reason for adding it to the main log file *by default* is because
of things like:
Customer: "My BIND went Boom! It's been running fine for many years,
and then for no reason at
asking customers to enable the additional
logs after a rare event (which might not happen again for months /
years) means that ISC cannot hunt down and squash the corner case
bugs...
W
> John
>
>
> -Original Message-
>
> From: Mukund Sivaraman <m...@isc.org>
> T
ve 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 <m...@isc.org>
To: Alan Clegg <a...@clegg.com>
Cc: bind-users@lists.isc.org
Subject: R
On 04-Feb-17 04:27, Phil Mayers wrote:
> On 03/02/17 16:45, Mukund Sivaraman wrote:
>
>> The query log is getting more fields at the end of it such as
>> CLIENT-SUBNET logging.
>
> Although it would be super-disruptive, has any thought been given to
> moving to an entirely new log format, for
On 04/02/2017 09:18, Phil Mayers wrote:
On 03/02/17 16:53, Alan Clegg wrote:
The "rndc" option allows those that KNOW that they may need the data
begin the collection where everyone else isn't impacted. If you know
that this customer is at risk, tell them "run this command, it's going
FWIW,
On 03/02/17 16:45, Mukund Sivaraman wrote:
The query log is getting more fields at the end of it such as
CLIENT-SUBNET logging.
Although it would be super-disruptive, has any thought been given to
moving to an entirely new log format, for example k/v or JSON? They're a
lot more extendable
On 03/02/17 16:53, Alan Clegg wrote:
The "rndc" option allows those that KNOW that they may need the data
begin the collection where everyone else isn't impacted. If you know
that this customer is at risk, tell them "run this command, it's going
FWIW, I would tend to agree with this
Hi there,
For the avoidance of doubt, It seems to me that the stability of BIND
has been improving over the last couple of years.
Thank you. Keep it up.
If I were hunting some rarely-seen fault condition, I think I'd write
any output which is more useful for debugging than anything else to a
On Fri, Feb 3, 2017 at 11:45 AM, Mukund Sivaraman wrote:
>
>
> 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
On 2/3/17 10:45 AM, Mukund Sivaraman wrote:
> On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote:
>> On 2/3/17 8:01 AM, Mukund Sivaraman wrote:
>> Adding code to allow enabling or disabling this output on the fly would
>> work MUCH better (as an example, see "rndc querylog"/ options
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
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
Hi John
On Fri, Feb 03, 2017 at 01:43:50PM +, MURTARI, JOHN wrote:
> Folks at ISC,
>
> > I agree, there are an awful lot of systems and SIEM products that
> > process querylogs. This one change will require a huge amount > of
> > re-engineering work in customer environments.
>
> You
Folks at ISC,
> I agree, there are an awful lot of systems and SIEM products that process
> querylogs. This one change will require a huge amount > of re-engineering
> work in customer environments.
You know we love you and the work you do! But changing that log format
was really a
.On Thu, Feb 2, 2017 at 2:24 PM, Paul Roberts
wrote:
> I agree, there are an awful lot of systems and SIEM products that process
> querylogs. This one change will require a huge amount of re-engineering
> work in customer environments.
>
>
Exactly
Mukund: We use
Sent: 25 January 2017 12:44
To: bind-users <bind-users@lists.isc.org>
Subject: Re: Bind Queries log file format
On 25 January 2017 at 10:59, Tony Finch <d...@dotat.at> wrote:
> It's the address in memory of the data structure representing the client.
> It is mentioned in the C
Hi Michael
On Wed, Jan 25, 2017 at 09:11:41AM -0500, Michael Dahlberg wrote:
> Mukund:
>
> Yea, I can respect that. However, I'm not confident that dropping it right
> in the middle of the log entry was the best place for it. I have a number
> of processes that monitor the query logs (it seems
On Wed, Jan 25, 2017 at 8:51 AM, Mukund Sivaraman wrote:
>
>
> 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
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 wrote:
> >> It's the address in memory of the data structure representing the client.
> >> It is mentioned in the CHANGES file (#4471)
On 1/25/17 7:44 AM, Steven Carr wrote:
> On 25 January 2017 at 10:59, Tony Finch 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
>>
On Wed, Jan 25, 2017 at 12:44:21PM +, Steven Carr wrote:
> On 25 January 2017 at 10:59, Tony Finch 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
> >
On 25 January 2017 at 10:59, Tony Finch 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
>
Michael Dahlberg wrote:
> I can discern what almost all of the fields signify except for the
> part "@0x7f6450002ef0".
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
30 matches
Mail list logo