Bug 196962 - NetworkManager init attempts to start named but fails
Summary: NetworkManager init attempts to start named but fails
Status: CLOSED DUPLICATE of bug 206604
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-27 20:35 UTC by Simon Goodall
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-10-13 12:11:43 UTC


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 12:21 UTC, James Ettle
no flags Details
Extracted named log entries before and after named restart (2.68 KB, text/plain)
2006-09-15 08:28 UTC, Simon Goodall
no flags Details

Description Simon Goodall 2006-06-27 20:35:06 UTC
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 23:39:53 UTC
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 15:49:57 UTC
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 21:32:40 UTC
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 19:00:35 UTC
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 14:51:36 UTC
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 21:48:59 UTC
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-14 00:48:28 UTC
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 08:12:50 UTC
Could you please attach named's output from /var/log/messgaes?

Comment 9 Martin Stransky 2006-09-14 09:52:15 UTC
If you don't restart named manually, which networks aren't available? Could you
attach bind configuration?

Comment 10 James Ettle 2006-09-14 10:34:34 UTC
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 12:11:36 UTC
(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 Ettle 2006-09-14 12:20:40 UTC
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 Ettle 2006-09-14 12:21:43 UTC
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 13:03:20 UTC
Yep, It looks like a DBUS problem, if you have an updated package please let me
know.

Comment 15 Simon Goodall 2006-09-15 08:28:46 UTC
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 08:30:18 UTC
Great! Thanks.

Comment 17 Simon Goodall 2006-09-15 08:31:57 UTC
I've been running my machine with selinux disabled so this is not a selinux issue.

Comment 18 Martin Stransky 2006-09-19 13:00:16 UTC
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 15:08:37 UTC
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 12:28:28 UTC
hm, and is it correct for your network? i.e. are these two right DNS servers?

Comment 21 Simon Goodall 2006-09-20 13:04:12 UTC
yes they are correct.

Comment 22 Martin Stransky 2006-10-13 12:11:43 UTC

*** 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.