Bug 489662

Summary: Bind exited with assertion related to result variable
Product: Red Hat Enterprise Linux 5 Reporter: masevac <masevac>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: low    
Version: 5.2CC: ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-11 10:25:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description masevac 2009-03-11 09:34:54 UTC
Hi, 
  I have 8 servers with named which are synchronized using rndc.
  Yesterday, 4 of the 8 server exited at the same time.
  After looking in logs, the only relevant lines I found is
---BEGIN---
Mar 10 13:01:03 server named[3334]: view.c:1116: INSIST(result == 0 || result == 23) failed
Mar 10 13:01:03 server named[3334]: exiting (due to assertion failure)
---END---

  In those server I have two different versions of CentOS (4.7 and 5.2) and so, different versions of named. Anyway 3 servers 4.7 and 1 server 5.2 stopped. The remaining server had not any problem. The also have CentOS versions 4.7 and 5.2, and the same named versions 9.2.4 and 9.3.4-P1
   

Version-Release number of selected component (if applicable):
9.2.4
9.3.4-P1

As far as I know the problem it's not reproducible

  
Actual results:
The named server exited

Expected results:
The named server will continue to run

Additional info:
I checked all named log lines, and there are not any more line relevant in the moment of the "sinchronized" exit. All warnings/errors are usual in log file, they are not only at moment of the exit.

Same as bug https://bugzilla.redhat.com/show_bug.cgi?id=489660 , but for different version of Bind/CentOS

Comment 1 Adam Tkac 2009-03-11 10:25:23 UTC
This problem is already fixed in RHEL 5.3.

*** This bug has been marked as a duplicate of bug 457533 ***