Bug 196962 - NetworkManager init attempts to start named but fails
NetworkManager init attempts to start named but fails
Status: CLOSED DUPLICATE of bug 206604
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-27 16:35 EDT by Simon Goodall
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-13 08:11:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
avc: denied messages from the log that seem to pertain to NetworkManager originated events. (20.25 KB, text/plain)
2006-09-14 08:21 EDT, James
no flags Details
Extracted named log entries before and after named restart (2.68 KB, text/plain)
2006-09-15 04:28 EDT, Simon Goodall
no flags Details

  None (edit)
Description Simon Goodall 2006-06-27 16:35:06 EDT
This was originally bug #194881 bug this no longer seems to exist

Description of problem:
The NetworkManger init script attempts to start the named service before
starting nm itself, however this fails on my system. See the following extract
from my log files.

Jun 12 09:42:38 echo named[1580]: starting BIND 9.3.2 -u named
Jun 12 09:42:38 echo named[1580]: found 1 CPU, using 1 worker thread
Jun 12 09:42:38 echo named[1580]: loading configuration from '/etc/named.conf'
Jun 12 09:42:38 echo named[1580]: no IPv6 interfaces found
Jun 12 09:42:38 echo named[1580]: ifiter_ioctl.c:532: REQUIRE(iter->pos <
(unsigned int) iter->ifc.ifc_len) failed
Jun 12 09:42:38 echo named[1580]: exiting (due to assertion failure)

Some googling on this issue suggested that named will not start because there
are no network interfaces up, which is of course happens because network manager
has not brought them up as it is not running.

Version-Release number of selected component (if applicable):
NetworkManager-0.6.2-2.fc5
NetworkManager-0.6.3-1.fc5
How reproducible:
Always

Steps to Reproduce:
1. Install latest NetworkManager and enable it at boot time
2. Make sure normal network service is disabled
3. Boot machine and observe status of named on boot
  
Actual results:
named fails to start

Expected results:
named should either be started or not started until a network interface comes up
(i.e. with a NetworkManagerDispatcher script)
Comment 1 Dan Williams 2006-07-09 19:39:53 EDT
Seems that named should work even if interfaces aren't up yet; nothing
guarantees that interfaces won't get hotplugged or unplugged at any time...  jason?
Comment 2 Jason Vas Dias 2006-07-10 11:49:57 EDT
Well, at least the loopback device should be up when named is started ...
but also named should NOT exit with an assertion failure if no interfaces
are found - I'll investigate and fix this in the next bind release.
Comment 3 Jason Vas Dias 2006-07-19 17:32:40 EDT
Actually, this is definitely fixed in the Rawhide versions >= 9.3.2-26 with the
fixes backported from ISC bind-9.3.3b1 CVS. 
I'm now applying these to FC-5 Updates/Testing with bind-9.3.2-22.fc5, now 
submitted to FC-5 Updates/Testing.

 
Comment 4 Fedora Update System 2006-07-22 15:00:35 EDT
bind-9.3.2-22.fc5 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 5 Simon Goodall 2006-08-08 10:51:36 EDT
I pulled this version from testing and tried it out.
named now starts up on boot with NetworkManager, however hostnames fail to
resolve until I restart named manually.
Comment 6 Simon Goodall 2006-09-12 17:48:59 EDT
bind-9.3.2-33.fc5 has just been installed on my machine through the normal
updates. This however still has the problem in comment #5 where I have to
manually restart named before hostnames will resolve.
Comment 7 Austin Jackson 2006-09-13 20:48:28 EDT
I can confirm the need to manually restart named with the most recent bind
updates (...-33)  Reverting to the previous version of bind revolves the issue.
Comment 8 Martin Stransky 2006-09-14 04:12:50 EDT
Could you please attach named's output from /var/log/messgaes?
Comment 9 Martin Stransky 2006-09-14 05:52:15 EDT
If you don't restart named manually, which networks aren't available? Could you
attach bind configuration?
Comment 10 James 2006-09-14 06:34:34 EDT
I'm seeing similar troubles here with the newly updated bind.

Prior to the updated, named startup would show "FAILED" on boot, but names
resolved correctly. Then I updated to bind-9.3.2-33.fc5 and it started up
properly, but names wouldn't resolved. I found NetworkManager reporting the
following:

NetworkManager: <WARNING> remove_all_zones_from_named (): Could not get
forwarder list from named. Error: 'An SELinux policy prevents this sender from
sending this message to this recipient (rejected message had interface
"com.redhat.named" member "GetForwarders" error name "(unset)" destination
"com.redhat.named")'.
NetworkManager: <WARNING> add_ip4_config_to_named (): Could not set forwarders
for zone '.'. Error: 'An SELinux policy prevents this sender from sending this
message to this recipient (rejected message had interface "com.redhat.named"
member "SetForwarders" error name "(unset)" destination "com.redhat.named")'.

and

NetworkManager: <WARNING>      add_ip4_config_to_named (): Could not set
forwarders for zone '.'.  Error: 'No reply within specified time'.

so assumed it was a SELinux/dbus issue. I tried relabeling --- didn't work; then
ran in Permissive mode, which also made no difference until I manually restarted
named and NetworkManager. I've now reverted back to

bind-9.3.2-20.FC5
bind-libs-9.3.2-20.FC5
bind-utils-9.3.2-20.FC5
caching-nameserver-7.3-5.FC5

and it works again (since in this case NetworkManager tinkers with
/etc/resolv.conf).

This is really odd because I've got another fully updated FC5 machine that
doesn't have these issues.
Comment 11 Martin Stransky 2006-09-14 08:11:36 EDT
(In reply to comment #10)
> I'm seeing similar troubles here with the newly updated bind.

Have you got any selinux AVC messages?
Could you attach your bind configuration?
Comment 12 James 2006-09-14 08:20:40 EDT
I can give you the "avc:  denied" messages in the logs (sorry if it's a bit
extensive; note that some of the denials may also come from me manually running
named{GS}etForwarders). Since I've reverted, I don't have the original bind
configuration that was causing the trouble (it was stock FC5, updated through
yum; no funny stuff, to the best of my knowledge). I'll try upgrading again via
yum later on and see if it goes awry again.
Comment 13 James 2006-09-14 08:21:43 EDT
Created attachment 136250 [details]
avc: denied messages from the log that seem to pertain to NetworkManager originated events.
Comment 14 Martin Stransky 2006-09-14 09:03:20 EDT
Yep, It looks like a DBUS problem, if you have an updated package please let me
know.
Comment 15 Simon Goodall 2006-09-15 04:28:46 EDT
Created attachment 136337 [details]
Extracted named log entries before and after named restart

This is the extracted named lines from /var/log/messages before and after a
named service restart.
Comment 16 Martin Stransky 2006-09-15 04:30:18 EDT
Great! Thanks.
Comment 17 Simon Goodall 2006-09-15 04:31:57 EDT
I've been running my machine with selinux disabled so this is not a selinux issue.
Comment 18 Martin Stransky 2006-09-19 09:00:16 EDT
how many network interfaces (and which) do you use? Do you use VPN and NM-VPN
plug-in?

Please run /usr/sbin/namedGetForwarders after boor (when resolving fails) and
after named restart and attach the outputs here.

Comment 19 Simon Goodall 2006-09-19 11:08:37 EDT
My machine has a wired card (eth0) and a wireless card (eth1). I also have the
pptp vpn stuff configured in network manager, but this is manually started
whenever I need it.

namedGetForwarders prints the same information before and after restrarting named.

.
        152.78.68.1
        152.78.70.1

Currently I've got the wired connection plugged in at boot time.
Comment 20 Martin Stransky 2006-09-20 08:28:28 EDT
hm, and is it correct for your network? i.e. are these two right DNS servers?
Comment 21 Simon Goodall 2006-09-20 09:04:12 EDT
yes they are correct.
Comment 22 Martin Stransky 2006-10-13 08:11:43 EDT

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

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