Description of problem: The recent bind-libds update no longer allows named to be restarted. Running service named restart results in the stop failing and the start failing with the error message that named is already running. I have to manually kill named to stop it. Version-Release number of selected component (if applicable): bind-libs-9.3.3-0.1.rc2.fc5 How reproducible: Always Steps to Reproduce: 1. Boot up machine. 2. Named starts with NetworkManager 3. No hostname resolve so need to restart named 4. run service named restart 5. fails, so killall named Actual results: Both stop and start fail Expected results: Named should restart with OK messages Additional info: This is a big issue for me due to bug #196962/#206604 which I did report while it was still in testing.
okay. btw. "service named reload" should work for you. Could you attach content of /var/log/messages when named fails to restart?
There's not a lot; Oct 17 10:33:48 echo named[1751]: rejected command channel message from 127.0.0.1#35066 The reload option does work however.
Could you please attach your /etc/named.conf?
Created attachment 138682 [details] named.conf My named.conf. Should just be the default.
I am experiencing the same problem on my FC5 box after updating to the latest version of bind packages. And I also have to manually restart named due to bug #206604. I also have the default named.conf, the same one as Simon.
Could you please run "/usr/sbin/rndc stop" and attach an output here?
Created attachment 139526 [details] Output of "/usr/sbin/rndc stop" command Here is the output of 'sudo /usr/sbin/rndc stop' on my FC5 box. I hope it helps.
(In reply to comment #7) > Created an attachment (id=139526) [edit] > Output of "/usr/sbin/rndc stop" command I don't see any problem here. What is return code of the "/usr/sbin/rndc stop" command? ($? shell variable). It should be zero... Have you got any messages on console?
The return code of command "sudo /usr/sbin/rndc stop" is zero and I don't get any messages at the console (as expected). However, running "sudo /sbin/service named stop" returns error code 1 and I get the "Stopping named: [FAILED]" error message at the console.
Please check the latest test update for FC5 (bind-9.3.3-0.2.rc2.fc5).
Hi! In the mean time, I updated my system to FC6 which now has bind-9.3.3-4.fc6 (from updates), but it still has the same problem with stopping named. There seems to be a mistake, because updates-testing repo for FC6 contains the packages of bind for FC5 (see http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/6/i386/). So, I think I should wait for a new test update for FC6 (perhaps version 30:9.3.3-6 from cvs?)
Update for FC6 is on the way.
I updated bind to version 9.3.3-6 today and now I get the following error: [tadej@tlinux-stable ~]$ sudo /sbin/service named restart Password: Stopping named: ..................................................no response, killing with -TERM [ OK ] Starting named: named: already running [FAILED] [tadej@tlinux-stable ~]$ sudo /sbin/service named reload Reloading named: [FAILED] [tadej@tlinux-stable ~]$ sudo /sbin/service named start Starting named: [ OK ] [tadej@tlinux-stable ~]$ Stopping named takes a very long time, but it has to be killed with -TERM, then immediately starting named also fails. Manually staring afterwards works OK. The relevant entries in /var/log/messages: Nov 7 17:52:49 localhost named[1523]: rejected command channel message from 127.0.0.1#43260 Nov 7 17:54:32 localhost named[1523]: shutting down Nov 7 17:54:32 localhost named[1523]: stopping command channel on 127.0.0.1#953 Nov 7 17:54:32 localhost named[1523]: exiting Nov 7 17:55:10 localhost named[2511]: starting BIND 9.3.3rc3 -u named -D Nov 7 17:55:10 localhost named[2511]: found 1 CPU, using 1 worker thread Nov 7 17:55:10 localhost named[2511]: loading configuration from '/etc/named.conf' Nov 7 17:55:10 localhost named[2511]: listening on IPv4 interface lo, 127.0.0.1#53 Nov 7 17:55:10 localhost named[2511]: listening on IPv4 interface eth0, 192.168.0.50#53 Nov 7 17:55:10 localhost named[2511]: command channel listening on 127.0.0.1#953 Nov 7 17:55:10 localhost named[2511]: zone 0.in-addr.arpa/IN: loaded serial 42 Nov 7 17:55:10 localhost named[2511]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 Nov 7 17:55:10 localhost named[2511]: zone 255.in-addr.arpa/IN: loaded serial 42 Nov 7 17:55:10 localhost named[2511]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700 Nov 7 17:55:10 localhost named[2511]: zone localdomain/IN: loaded serial 42 Nov 7 17:55:10 localhost named[2511]: zone localhost/IN: loaded serial 42 Nov 7 17:55:10 localhost named[2511]: D-BUS dhcdbd subscription disabled. Nov 7 17:55:10 localhost named[2511]: D-BUS service enabled. Nov 7 17:55:10 localhost named[2511]: running Nov 7 17:55:35 localhost NetworkManager: <WARNING> add_ip4_config_to_named (): Could not set forwarders for zone '.'. Error: 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'. The first message seems to indicate there is still a problem with permissions for stopping named (I'm not using SELinux, if that has anything to do with it).
Could you please check it as a root? (not under sudo)
Hmm, something strange is going on here. If I try 'service named restart' right after Fedora boots up, it seems to hang trying to stop named. The same thing happens for root and sudo. If I execute 'service named reload' (as sudo) it finishes immediately and the subsequent executions of command 'service named restart' work immediatelly (both for root and sudo). I don't know what is 'special' about the first attempt to stop (and restart) the named service, because subsequent attempts (after waiting for a very long time for named to stop or executing 'service named reload' in between to 'fix' the issue) to restart named work flawlessly. Note: I have to restart named after startup due to bug in NetworkManager: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206604 (I'm waiting for your patch to be applied to NetworkManager).
I had similar problem, and solved by adding: inet ::1 allow { localhost; } keys { rndckey; }; to /etc/named.conf, insite the controls directive. Note the IPv6 address. This seems to be caused due to ::1 listed as the localhost address in /etc/hosts.
It should be fixed in bind-9.3.3-0.1.rc3.fc6 / bind-9.3.3-0.1.rc3.fc7.