Hello,
I got a very strange issue for 10 min ago. I added new domain name in the DNS server via Virtualmin, and once the domain name was added, configured NS server and A records etc... and than applied the configuration I received an error:
Failed to start BIND : Starting named: [FAILED]
than I run error check for BIND and nothing was displayed... and I am not able to start the BIND at all, each time when I try to start it I receive the same error message:
Failed to start BIND : Starting named: [FAILED]
any idea why this happens ?? I cannot see any reasons for this issue ...
Running a BIND ver: 9.7.3
Thank You
BIND should have logged more details about the error in /var/log/syslog, you might want to check there.
thank You for reply, are You sure that error log is in this location /var/log/syslog ? I am using CentOS 6 and I do not have these logs in that location...
not sure if this is the right file, because this is the file and location I found in the named.conf for logging.
/var/named/data/named.run
CentOS logs to different locations then probably. BIND usually logs to syslog though, so you'd need to find out where the syslog file is located under CentOS. The .run file you mentioned is probably just a run semaphore, i.e. a file whose presence means "BIND is running" and which usually contains the process ID.
I could not find the log file for BIND, but any way I think that problem could be file location:
older BIND ver: /var/named/ newer BIND ver: /var/named/chroot
I noticed this because I run a backup on the old server and reinstalled whole server than when I restored a Webmin (BIND) backup non of the domains was in the BIND list and restore was successfull.
Than I saw that files was restored in the following location:
/var/named/
while the BIND on the new installed server is looking for the files in the following location:
/var/named/chroot
so how can I fix these references, it makes me really crazy why they are changing these locations all the time what`s the point ???
I hope that someone can help me on this issue...
Thank You
Amel
or the new Webmin module newly updated caused this issue, because when we run Webmin upgrade for couple weeks ago, than when we are creating the domain names in the BIND the zone files are added to:
/var/named/chroot
instead to:
/var/named/
or ?
If you're using CentOS, the BIND logs are in /var/log/messages.
Webmin/Virtualmin doesn't choose where BIND files are stored -- it simply looks at your current BIND configs, and attempts to figure out where BIND is configured to store them.
So updating Webmin or Virtualmin should not have caused that issue.
If you look in /etc/sysconfig/named, is ROOTDIR set in there?
-Eric
thank You very much for reply Eric.
I will remember about the log file location. Regarding the ROOTDIR, below is the configuration I found in:
/etc/sysconfig/named
# BIND named process options# ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Currently, you can use the following options:
#
# ROOTDIR="/var/named/chroot" -- will run named in a chroot environment.
# you must set up the chroot environment
# (install the bind-chroot package) before
# doing this.
# NOTE:
# Those directories are automatically mounted to chroot if they are
# empty in the ROOTDIR directory. It will simplify maintenance of your
# chroot environment.
# - /var/named
# - /etc/pki/dnssec-keys
# - /etc/named
# - /usr/lib64/bind or /usr/lib/bind (architecture dependent)
#
# Those files are mounted as well if target file doesn't exist in
# chroot.
# - /etc/named.conf
# - /etc/rndc.conf
# - /etc/rndc.key
# - /etc/named.rfc1912.zones
# - /etc/named.dnssec.keys
# - /etc/named.iscdlv.key
#
# Don't forget to add "$AddUnixListenSocket /var/named/chroot/dev/log"
# line to your /etc/rsyslog.conf file. Otherwise your logging becomes
# broken when rsyslogd daemon is restarted (due update, for example).
#
# OPTIONS="whatever" -- These additional options will be passed to named
# at startup. Don't add -t here, use ROOTDIR instead.
#
# KEYTAB_FILE="/dir/file" -- Specify named service keytab file (for GSS-TSIG)
#
# DISABLE_ZONE_CHECKING -- By default, initscript calls named-checkzone
# utility for every zone to ensure all zones are
# valid before named starts. If you set this option
# to 'yes' then initscript doesn't perform those
# checks.
if the file location isn
t a problem than I cannot understand why its happening... This happened actually suddenly without any changes in the configurations, this is an up-to date patched server as we are updating it always when new updates are out, so I just created a new domain name and added A Records, NS, MX etc... just on the same way as we did it for other domains we are running from before... and the BIND just stopped and I was not able to start it at all...Than I tried to install a fresh server and just take a Webmin BIND backup and tried to restore it on the new server and restore went just fine, but however I was not able to see restored domain names in the BIND.. there was no domain names in the list, no zones, everything looks just like before restore...
now I am back on the old server where BIND service is down ... I would just check with new install if that could help but not... so I need some help to figure out what`s going on on this server why BIND service stops after creating a new domains...
here is the final update:
you told me:
"So updating Webmin or Virtualmin should not have caused that issue"
But I have to ask are You 100% sure about it ? I am asking because, this server is running on VMWare and I was able to restore the previous SNAPSHOT so not when I log-on to Webmin-virtualmin I see that there is an update because this is restored to an earlier ver...
Webmin: 1.580-1 usermin: 1.500-1
and now I am running:
Webmin: 1.570 usermin: not related in this case...
when I am running Webmin 1.570 it works fine to add new domains no problems at all, but once I update the Webmin to latest ver: 1.580-1 than this issue occurs ...
So there is issue when we are running latest Webmin ver: 1.580-1, once we create new domain in DNS "Master" zone than DNS service goes down and I cannot start it...
will dig on to this issue right ahead and try to find out what causes this issue...
I will not say that I have 100% right about this yet, but this is as far as I have tested it now...
Amel
this is the latest log from:
/var/log/messages
Feb 26 20:44:34 srv1 named[1090]: shutting downFeb 26 20:44:34 srv1 named[1090]: no longer listening on ::#53
Feb 26 20:44:34 srv1 named[1090]: no longer listening on 127.0.0.1#53
Feb 26 20:44:34 srv1 named[1090]: no longer listening on xx.xx.xx.xx#53
Feb 26 20:44:34 srv1 named[1090]: exiting
Feb 26 20:44:36 srv1 named[4596]: starting BIND 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2 -u named
Feb 26 20:44:36 srv1 named[4596]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target$
Feb 26 20:44:36 srv1 named[4596]: adjusted limit on open files from 1024 to 1048576
Feb 26 20:44:36 srv1 named[4596]: found 4 CPUs, using 4 worker threads
Feb 26 20:44:36 srv1 named[4596]: using up to 4096 sockets
Feb 26 20:44:36 srv1 named[4596]: loading configuration from '/etc/named.conf'
Feb 26 20:44:36 srv1 named[4596]: none:0: open: /etc/named.conf: permission denied
Feb 26 20:44:36 srv1 named[4596]: loading configuration: permission denied
Feb 26 20:44:36 srv1 named[4596]: exiting (due to fatal error)
Here is the permission for named.conf file
[root@srv1 ~]# ls /etc/named.conf -l
-rw-r----- 1 root root 2076 Feb 26 21:32 /etc/named.conf
this is chmod 640
But I have not changed any permissions .... which permission we should have here ?? could Webmin update change it perhaps ??
But I have to ask are You 100% sure about it ? I am asking because, this server is running on VMWare and I was able to restore the previous SNAPSHOT so not when I log-on to Webmin-virtualmin I see that there is an update because this is restored to an earlier ver...
Is Webmin the only software version to change? Or has other software been modified too?
-Eric
I have tested it several times, I updated all other packages except Webmin and DNS BIND works fine, but once I run Webmin update from 1.570 to 1.580 than this issue occurs ...
Amel
I also have this error. Few weeks ago all was going just fine on CentOS 6.2. Now I have this problem too. I don't know who make this changes virtualmin or centos packages but what we do:
from terminal install "yum install bind-chroot" and restart can only killing named process and starting it again.
I installed with Virtualmin GPL script.
Hello Jahsis,
so You fixed this issue installing bind-chroot ?
I agree with You either Virtualmin or CentOS, but I think in this case it could be Webmin issue, I will not say 100% but this happens once I upgrade the Webmin, while I have updated all other patches and no problems at all... but once I update to latest Webmin than this error occurs..
Howdy,
You may want to add a comment about what you're seeing to this bug report here:
http://www.virtualmin.com/node/20420
there is already some registered issues regarding this issue I assume, and if I post anything more there than it will make a confusion...
But other problem here is that I cannot start DNS on new fresh installed Virtualmin either... all of the other services are started except DNS, so I cannot understand what is so complicated about BIND that it has to be so difficult to get it started once the Virtualmin is installed ? any special reason ?
Isn`t it possible to make some "template" config that can be used within DNS so it starts normally as other services... ?
Thank You for helping !
Amel
Is BIND not running? Or does Virtualmin just say BIND isn't running?
If it's the latter, then that's simply a related issue to everything else you've described.
It it's the former -- what error(s) do you get while trying to start it? What shows up in /var/log/messages when you attempt to start it?
-Eric
I have now checked it again, it seems that You`re right, the BIND is running when I verified it via CLI
[root@srv1 ~]# service named restartStopping named: .[ OK ]
Starting named: [ OK ]
[root@srv1 ~]#
But Webmin says that BIND is down... so there has to be some issue with Webmin in this case ? I am not 100% sure, but what else it could be ...
I think that Webmin version 1.580 should be checked by Jamie or ?
PS: have tried to create a new master zone via Webmin, and when I create the ZONE I have to manually REFRESH bind in the browser in order to be able to see that zone in the list. Than when I tried to create some records within this zone, I received following error:
Failed to save record : Failed to open /var/named/chroot/var/named/mydomain.com.hosts for writing : Bad file descriptor
And these issues I mentioned in this last post are tested in clean installed CentOS 6 and Webmin/Virtualmin installed from install.sh ...
Amel
Jamie is looking into all that. There's some fixes for the specific issues you mentioned in the bug report though, those are things you could apply now while waiting for his formal fix.
-Eric
I saw what Jamie wrote, I will try to do so as workaround until final patch is released..
Thank You for helping
Amel
this is what Jamie wrote:
Stop BIND Edit /etc/sysconfig/named and remove the ROOTDIR line. Start BIND again
BUT here is mine /etc/sysconfig/named output, as You will notice all the lines are commented and not in use, so there is no point to remove anything here as it is not in use ... I do not understand ...
# BIND named process options# ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Currently, you can use the following options:
#
# ROOTDIR="/var/named/chroot" -- will run named in a chroot environment.
# you must set up the chroot environment
# (install the bind-chroot package) before
# doing this.
# NOTE:
# Those directories are automatically mounted to chroot if they are
# empty in the ROOTDIR directory. It will simplify maintenance of your
# chroot environment.
# - /var/named
# - /etc/pki/dnssec-keys
# - /etc/named
# - /usr/lib64/bind or /usr/lib/bind (architecture dependent)
#
# Those files are mounted as well if target file doesn't exist in
# chroot.
# - /etc/named.conf
# - /etc/rndc.conf
# - /etc/rndc.key
# - /etc/named.rfc1912.zones
# - /etc/named.dnssec.keys
# - /etc/named.iscdlv.key
#
# Don't forget to add "$AddUnixListenSocket /var/named/chroot/dev/log"
# line to your /etc/rsyslog.conf file. Otherwise your logging becomes
# broken when rsyslogd daemon is restarted (due update, for example).
#
# OPTIONS="whatever" -- These additional options will be passed to named
# at startup. Don't add -t here, use ROOTDIR instead.
#
# KEYTAB_FILE="/dir/file" -- Specify named service keytab file (for GSS-TSIG)
#
# DISABLE_ZONE_CHECKING -- By default, initscript calls named-checkzone
# utility for every zone to ensure all zones are
# valid before named starts. If you set this option
# to 'yes' then initscript doesn't perform those
# checks.
I would like to make a comment on this because the same thing has happened to me.
Whenever I manually add a new domain "Create master zone", and apply the zone/configuration BIND will fail to restart.
This happens because the permissions for /etc/named.conf get changed to root root
I then have to manually do chown root:named /etc/named.conf
Hope this helps everyone understand this issue more so it can fixed.
Also please note adding domains through "Create Virtual Server" do NOT cause this issue.
There’s a better solution to this irritating problem. From Webmin’s main BIND page, click “Module Config”. Choose “Zone file options” from the drop down list. Change “Owner for zone files” from “Default” to “root:named”.
Had this provlem following DNS Configuration instructions on http://www.virtualmin.com/documentation/cloudmin/gettingstarted for Cloudmin. Rob's advice solved the issue.