Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionDaniel McNamara
2012-07-03 03:21:29 UTC
Description of problem:
Ever since BIND update in RHEL 6.3 round up named crashing with assertion failures, appears to be triggered by non valid queries (yet to manually confirm this however)
Version-Release number of selected component (if applicable):
bind-chroot-9.8.2-0.10.rc1.el6.x86_64
bind-9.8.2-0.10.rc1.el6.x86_64
bind-utils-9.8.2-0.10.rc1.el6.x86_64
bind-libs-9.8.2-0.10.rc1.el6.x86_64
How reproducible:
So far unable to locate query type that causes the crash, has occurred several times since package update however.
Steps to Reproduce:
1. Update RHEL 6.3 to bind-9.8.2-0.10.rc1.el6.x86_64
2. Run script with multiple invalid query types
3. Named crashes with assertion failure
Actual results:
Named crashes out:
--
Jun 26 19:19:47 f2 named[16303]: error (network unreachable) resolving 'attendee.role.req.participant.partstat.needs.action.rsvp.true.cn.sdowns.aom.c.org/A/IN': 2001:500:22::254#53
Jun 26 19:19:49 f2 named[16303]: rbtdb.c:1619: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 26 19:19:49 f2 named[16303]: exiting (due to assertion failure)
--
Jun 27 03:20:12 f2 named[17699]: error (connection refused) resolving 'zapaska.biz/A/IN': 74.208.64.145#53
Jun 27 03:20:13 f2 named[17699]: rbtdb.c:1619: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 27 03:20:13 f2 named[17699]: exiting (due to assertion failure)
--
Jun 28 06:53:03 f2 named[30490]: validating @0x7ff4f80a38a0: I60UU5FGC7SPHUOLS5OC7RKBT1EJ66RG.tw NSEC3: no valid signature found
Jun 28 06:53:04 f2 named[30490]: rbtdb.c:1857: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 28 06:53:04 f2 named[30490]: exiting (due to assertion failure)
--
Jun 29 21:47:26 f2 named[25616]: error (network unreachable) resolving 'm2.nstld.net/A/IN': 2001:503:231d::2:30#53
Jun 29 21:47:26 f2 named[25616]: rbtdb.c:1619: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 29 21:47:26 f2 named[25616]: exiting (due to assertion failure)
--
Jun 30 01:32:20 f2 named[13112]: error (network unreachable) resolving 'ns2.byet.org/AAAA/IN': 2001:500:40::1#53
Jun 30 01:32:20 f2 named[13112]: rbtdb.c:1857: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 30 01:32:20 f2 named[13112]: exiting (due to assertion failure)
--
Jun 30 20:05:43 f2 named[7233]: validating @0x7f4bd008b5d0: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.net NSEC3: no valid signature found
Jun 30 20:05:45 f2 named[7233]: rbtdb.c:1511: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jun 30 20:05:45 f2 named[7233]: exiting (due to assertion failure)
--
Jul 2 13:25:06 f2 named[26254]: validating @0x7ffa5400fc30: 3RL0HJSI26SCTO21AV9TVIGIPUVPJAI1.com NSEC3: no valid signature found
Jul 2 13:25:08 f2 named[26254]: rbtdb.c:1511: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jul 2 13:25:08 f2 named[26254]: exiting (due to assertion failure)
--
Jul 3 02:43:16 f2 named[3275]: error (unexpected RCODE SERVFAIL) resolving 'academyunion.net/AAAA/IN': 67.220.238.207#53
Jul 3 02:43:16 f2 named[3275]: rbtdb.c:1619: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
Jul 3 02:43:16 f2 named[3275]: exiting (due to assertion failure)
--
Expected results:
DNS requests should not be causing named to crash out on an assertion failure
Additional info:
Machines that have shown this so far are not IPv6 enabled - this may or may not be relevant to the issue
Hey guys,
This issue is become extremely problematic and is occurring 2 -3 times each day. I've had to put a script in place that restarts the named service on death - this is not an appropriate long term solution.
I still haven't located any one particular request that can trigger the crash but it is becoming extremely frustrating. Has there been any movement on this bug?
We're seeing this on a regular basis too.
What's the timeline for getting an erratum issued for this? It definitely looks like 3284 is the right fix to backport, assuming a rebase against 9.8.2 final isn't in the cards.
We started to see this more and more frequently in our infra.
I'd say this should be a blocker bug since production DNS servers are affected by this unresolved issue.
Do we have any timeframe by when the fix would be out for this issue?
We recently migrated all of our DNS from Solaris to RHEL. And, this bug gave our management an opportunity to rollback everything back to Solaris. Unless we have patch soon, we may have to bid RHEL goodbye as far as DNS is concerned.
(In reply to comment #23)
> Do we have any timeframe by when the fix would be out for this issue?
>
> We recently migrated all of our DNS from Solaris to RHEL. And, this bug gave
> our management an opportunity to rollback everything back to Solaris. Unless
> we have patch soon, we may have to bid RHEL goodbye as far as DNS is
> concerned.
Please check bug #838956 and http://rhn.redhat.com/errata/RHBA-2012-1107.html. This issue is already fixed, just update to the latest released packages.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0475.html