Bug 149183 - named fails assertion ifa->ifa_addr not null
Summary: named fails assertion ifa->ifa_addr not null
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Ben Levenson
URL:
Whiteboard:
: 149263 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-20 12:42 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: bind-9.3.1rc1-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-02-21 21:44:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2005-02-20 12:42:33 UTC
Description of problem:
On both of my rawhide-tracking boxes, named died after yesterday's
rawhide update.  /var/log/messages explained:

Feb 19 19:51:55 livre named[11514]: starting BIND 9.3.1rc1 -u named -t
/var/named/chroot
Feb 19 19:51:55 livre named[11514]: found 1 CPU, using 1 worker thread
Feb 19 19:51:55 livre named[11514]: loading configuration from
'/etc/named.conf'
Feb 19 19:51:55 livre named[11514]: ifiter_getifaddrs.c:109:
INSIST(ifa->ifa_addr != ((void *)0)) failed
Feb 19 19:51:55 livre named[11514]: exiting (due to assertion failure)

The one common theme between these boxes is the fact that they have
some openvpn and vpnc tun devices in use, as well as a lo:0 alias to
their home IP addr.

The funcional bind-9.3.0-2 used to say:

Feb 19 20:10:30 livre named[12319]: starting BIND 9.3.0 -u named -t
/var/named/chroot
Feb 19 20:10:30 livre named[12319]: found 1 CPU, using 1 worker thread
Feb 19 20:10:31 livre named[12319]: loading configuration from
'/etc/named.conf'
Feb 19 20:10:31 livre named[12319]: listening on IPv4 interface lo,
127.0.0.1#53
Feb 19 20:10:31 livre named[12319]: listening on IPv4 interface lo:0,
172.31.160.2#53
Feb 19 20:10:31 livre named[12319]: listening on IPv4 interface tun2,
172.31.160.19#53
Feb 19 20:10:31 livre named[12319]: listening on IPv4 interface tun1,
172.31.160.21#53
Feb 19 20:10:31 livre named[12319]: listening on IPv4 interface tun0,
172.16.50.43#53
Feb 19 20:10:31 livre named[12319]: command channel listening on
127.0.0.1#953
Feb 19 20:10:31 livre named[12319]: zone 0.in-addr.arpa/IN: loaded
serial 42
[...]

BTW, downgrading to the previous version of bind-*.rpm didn't
immediately work on x86_64, because the SONAMEs were still pointing to
the newer, just-removed version.  That's odd, because ldconfig is
present in the %postuninstall script, but I thought I'd mention it anyway.

Version-Release number of selected component (if applicable):
bind-9.3.1rc1-1

How reproducible:
Always

Steps to Reproduce:
1.service named restart

Comment 1 Jason Vas Dias 2005-02-20 20:42:44 UTC
I added the '--enable-getifaddrs' flag to the configure in 9.3.1rc1-1
because apparently ioctl(..,SIOCGIFCONF,..) is deprecated
(see bug 138181). I've now removed it in bind-9.3.1rc1-2 so that 
bind will now use the same method as before - it seems getifaddrs()
has a bug in glibc-2.3.4-10 . Also, bind-9.3.0-2 had a 'ldconfig' at
the end of the 'bind' package's %postun; I had thought this would be
redundant since 'bind-libs' %postun is '%postun libs-p/sbin/ldconfig';
I guess not, so I'm adding ldconfig back to bind's
%postun . 
bind-9.3.1rc1-2 is now being built with these changes and should be
in rawhide-2005-02-21 .


Comment 2 Jason Vas Dias 2005-02-21 19:36:24 UTC
*** Bug 149263 has been marked as a duplicate of this bug. ***

Comment 3 Alexandre Oliva 2005-02-21 21:44:40 UTC
Confirmed fixed, thanks.  Now...  Are you sure the problem with getifaddrs is
actually in glibc, and not in named proper?  It would be nice to figure that
out, such that we could switch to the newer POSIX calls.


Note You need to log in before you can comment on or make changes to this bug.