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)
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?
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.
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.
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.
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.
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.
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.
Could you please attach named's output from /var/log/messgaes?
If you don't restart named manually, which networks aren't available? Could you attach bind configuration?
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.
(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?
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.
Created attachment 136250 [details] avc: denied messages from the log that seem to pertain to NetworkManager originated events.
Yep, It looks like a DBUS problem, if you have an updated package please let me know.
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.
Great! Thanks.
I've been running my machine with selinux disabled so this is not a selinux issue.
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.
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.
hm, and is it correct for your network? i.e. are these two right DNS servers?
yes they are correct.
*** This bug has been marked as a duplicate of 206604 ***