Skip Menu |
Report information
The Basics
Id: 46942
Status: resolved
Priority: 50/50
Queue: bind9-public

People
Bug Information
Version Fixed: 9.12.1, 9.13.0
Version Found: (no value)
Versions Affected: (no value)
Versions Planned: (no value)
Priority: P2 Normal
Severity: S2 Normal
CVSS Score: (no value)
CVE ID: (no value)
Component: (no value)
Area: bug

Dates
Created:Tue, 02 Jan 2018 17:03:32 -0500
Updated:Wed, 21 Feb 2018 18:01:49 -0500
Closed:Fri, 16 Feb 2018 05:50:46 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Date: Tue, 2 Jan 2018 22:03:28 +0000
To: bind-bugs@isc.org
From: "Jay Ford" <jnford@uiowa.net>
Subject: BIND 9.12.0rc1 - DNSTAP output file rolling trouble
Bug Report from www.isc.org: Name: Jay Ford Email: jnford@uiowa.net Software Version: BIND 9.12.0rc1 OS: Linux dns-ph-1 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux Subject:DNSTAP output file rolling trouble Bug Detail =========== It looks like multiple things (named worker threads?) are rolling the DNSTAP output files without any coordination. I see multiple roll logs at the same time, mangled file version sequencing, & writing to multiple output files simultaneously. I've also seen 3 instances of named crashing immediately after logging about a DNSTAP file roll. I can provide the build details, named config, logs, output file directory output, & a core file from a crash. --- This email was received through isc.org Bug Submission Form
Hi Jay, Thank you for reporting this. The problem will be fixed in 9.12.1 by the following change: 4894. [bug] named could crash while rolling a dnstap output file. [RT #46942] Note, however, that we are considering dropping support for size-based rolling of dnstap output files altogether in BIND 9.13.0, unless the feature will become supported directly by the fstrm library. No decisions regarding removal have yet been made, though, this is just a heads-up that things might change in the not so distant future.