Basically the title describes the problem. I did a fresh install of CentOs 6.2 and ran the Virtualmin setup script. It had one error with Perl not being installed (or a specific module?) anyway got that fixed and ran the installer, ran the setup and everything was fine.
However, now the issue is BIND has an X beside it. clicking the start button does nothing. Running /etc/init.d/named start says it's already running.
Running named status says " rndc: neither /etc/rndc.conf nor /etc/rndc.key was found named (pid 29250) is running..." so that may be something I don't know.
Has anyone run into this issue that's able to give me some advice? Thanks
Howdy,
My suspicion is that BIND is running just fine, but that it's just now showing as running in the Virtualmin GUI.
The first place to start here would be to just restart BIND from the command line, like so:
/etc/init.d/named restartAnd then give Virtualmin a restart:
/etc/init.d/webmin restartAfter that, does it show up correctly?
-Eric
Thanks Eric,
I tried that (should have mentioned I rebooted the server as well just incase) but the same issue remains.
I should also mention I did all the Virtualmin and system updates, so I'm not sure if it's a bug or if I did something wrong.
Though I think you're right, named is probably working just fine, I just want to make sure before I start setting up sites on it this server :)
Thanks again.
Howdy,
What output do you get if you log into your server, and run this command:
netstat -an | grep :53That should show if BIND is running or not.
-Eric
Hi, i'm having the exact same problem. I tried everything above, and it still shows as not running in virtualmin. Because this is my first time setting up a VPS I could have other problems rooted elsewhere but I can't get BIND to start, which would atleast be a start!. I ran the netstat -an | grep :53 command and received:
tcp 0 0 123.2ND.IP.321:53 0.0.0.0:* LISTEN tcp 0 0 123.1ST.IP.321:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 123.2ND.IP.321:53 0.0.0.0:*
udp 0 0 123.1ST.IP.321:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
123.1ST.IP.321 aand 123.2ND.IP.321 are obviously my first and second ip addresses
UPDATE: I just tried to create a virtual server for another domain i am wanting to host and as it was running through, it said: Re-starting DNS server .. .. not running!
So I assume its definately not running?
Look under webmin-system-running processes. Select User and find Named. If you see named running there then its likely due that webmin doesn't see it in this centos 6.2
the solution is to go to Webmin bind module-module config-tab "Bind Paths" -
and set:
Chroot directory to run BIND under None
Is named.conf under chroot directory? No
I did the above, restarted the server and tried starting BIND again but it didnt work, but I checked the running processes and saw: 1469 named 15:45 /usr/sbin/named -u named -t /var/named/chroot
am I safe to assume that it is actually running?
UPDATE: even though it is still in running processes, and still says BIND is stopped in the module/server information, the nameservers I have tried to set on the same domain are not resolving.
It does appear as if BIND is running.
You can determine that by running this command:
dig @localhost
That should return a series of root nameservers if it's running properly.
-Eric
Thanks ronald, that worked just fine. Thank you too Eric, it also showed me it was running. I understand this is a bug of webmin?
webmin should by default not choose chroot. It will be fixed in the next release.
This behaviour is different because centos 6 has different behaviours in comparison to earlier releases.