Reload of named.service fails, and multiple named processes on Debian 9

kristian

Verified User
Joined
Nov 4, 2005
Messages
436
Location
Norway
Greetings!

I am experiencing a problem with bind not reloading properly on one of our servers. On an identical server, it is working as it should, but it has some strange issues as well. I can't figure out why they are different, or why one of them is failing to reload bind. Both servers have been set up using Ansible (automation), so they should be exactly the same.

The first issue is the reload problem on web32. The error in the log is:

Code:
Apr  4 11:26:01 web32 systemd[1]: named.service: Unit cannot be reloaded because it is inactive.

And sure enough, when checking the status for named.service, this is the output on web32:

Code:
# systemctl status named.service
● named.service - BIND Domain Name Server
   Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-03-25 14:29:29 CET; 1 weeks 2 days ago
     Docs: man:named(8)
 Main PID: 4241 (code=exited, status=0/SUCCESS)

Apr 03 12:37:02 web32 systemd[1]: named.service: Unit cannot be reloaded because it is inactive.

While on web33, where everything works as expected, the output is different:

Code:
# systemctl status named.service
● named.service - BIND Domain Name Server
   Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-04-02 17:02:25 CEST; 1 day 18h ago
     Docs: man:named(8)
 Main PID: 18657 (named)
    Tasks: 7 (limit: 4915)
   CGroup: /system.slice/named.service
           └─18657 /usr/sbin/named -f -u bind

Apr 04 09:40:25 web33 rndc[24184]: server reload successful

If I check the status of bind9.service on the two servers, they show this for Web32:

Code:
# systemctl status bind9.service 
● bind9.service - LSB: Start and stop bind9
   Loaded: loaded (/etc/init.d/bind9; generated; vendor preset: enabled)
   Active: active (running) since Thu 2019-04-04 10:05:57 CEST; 1h 50min ago
     Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/bind9.service
           └─12475 /usr/sbin/named -u bind

And web33:

Code:
# systemctl status bind9.service
● bind9.service - LSB: Start and stop bind9
   Loaded: loaded (/etc/init.d/bind9; generated; vendor preset: enabled)
   Active: active (running) since Thu 2019-04-04 10:08:35 CEST; 1h 48min ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 7 (limit: 4915)
   CGroup: /system.slice/bind9.service
           └─26631 /usr/sbin/named -u bind

Both servers have /etc/init.d/bind9 and /etc/systemd/system/named.service and they are identical.

Looking at the processlist on each server, I see two named processes running, which I find strange. In addition, the two servers are different in that regards as well:

Web32:

Code:
# ps auxfww | grep name[d]
root     21444  0.0  0.2 389260 21364 ?        Ssl  Mar21   0:12 named
bind     12475  0.0  0.3 411260 26788 ?        Ssl  10:05   0:01 /usr/sbin/named -u bind

Web33:

Code:
# ps auxfww | grep name[d]
bind     18657  0.0  0.3 411000 26332 ?        Ssl  Apr02   0:09 /usr/sbin/named -f -u bind
bind     26631  0.0  0.3 407620 29176 ?        Ssl  10:08   0:00 /usr/sbin/named -u bind

The servers are both running Debian 9(.8), Linux 4.9.0-5-amd64 x86_64, with Directadmin 1.56:

Code:
# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.8 (stretch)
Release:	9.8
Codename:	stretch

# uname -srm
Linux 4.9.0-5-amd64 x86_64

# /usr/local/directadmin/directadmin o
Compiled on 'Debian 9.0 64-bit'
Compile time: Mar 18 2019 at 02:18:53
Timestamp: '1552897108'
Compiled with IPv6

# /usr/local/directadmin/directadmin v
Version: DirectAdmin v.1.56.0

So I guess my three questions are:

1 - Why do one of my servers have an inactive named.service? A reload of bind9.service works as expected.
2 - Why do I have two named processes running in the first place?
3 - How do I resolve 1 and 2? :)

This is confusing me bigtime. Any help appreciated!
 
Ah, that is useful indeed. Not sure what has happened on my servers to cause one to work without that setting, and the other to not work though.
 
For some reason, when setting named_service_override=bind9 in the directadmin.conf file, and restarting directadmin, there seems to be no attempt whatsoever to reload bind. I can't see any trace of DirectAdmin even trying in any of the logs. The changed zone is not available if I query the local named either.
 
Last edited:
A few steps to test with:
  1. Add/remove a test record from any dns zone. Quickly type:
    Code:
    cat /usr/local/directadmin/data/task.queue
    to see if DA has added the changed value for the action. If not, confirm the setting with
    Code:
    ./directadmin c | grep named_service_override
  2. If you do see the correct action, you can manually test it, repeatedly by dumping the same thing to the task.queue again, and running the dataskq with
    Code:
    cd /usr/local/directadmin
    echo 'action=bind9&value=reload' >> data/task.queue; ./dataskq d2000
    and check /var/log/directadmin/system.log to see if mentinos bind9 or not.

John
 
After changing a DNS zone, /usr/local/directadmin/data/task.queue contained:

Code:
action=bind%39&value=reload

So it seems the 9 is urlencoded before inserted for some reason. The config does not contain the urlencoded value:

Code:
# ./directadmin c | grep named_service_override
named_service_override=bind9

I also tried manually inserting it with a proper name:

Code:
echo 'action=bind9&value=reload' >> /usr/local/directadmin/data/task.queue

In both these cases, nothing was logged to /var/log/directadmin/system.log or /var/log/directadmin/errortaskq.log or anywhere else that I could find, but the entry in the queue file disappeared.
 
URL encoding shouldn't affect anything, as it's decoded in the dataskq.
I'm interested in the dataskq output, so please run it through as described in #2 of my previous post.

John
 
Apologies, I expected it to show in the log as well. Here's the output:

Code:
# echo 'action=bind9&value=reload' >> data/task.queue; ./dataskq d2000
Debug mode. Level 2000

root priv set: uid:0 gid:0 euid:0 egid:0
pidfile written
starting queue
dataskq: command: action=bind9&value=reload
done queue
 
This has been fixed in DirectAdmin version 1.57. When making a zone change now, I see the following in /var/log/directadmin/system.log:

Code:
2019:05:30-23:04:01: bind9 reloaded
2019:05:30-23:04:03: bind9 restarted

Probably not necessary to do both a reload and a restart, but it works.
 
The "wrong" named will start on reboot, so in order to resolve that, disable named and enable bind9:

Code:
systemctl disable named.service
systemctl enable bind9.service
 
Last edited:
I have the same issue and I tried adding named_service_override=bind9 to directadmin.conf
but after restarting DA and trying to restart bind9 I get an error that it doesn't exist.
For some weird reason, even though named is not installed as a service on Ubuntu Focal, when you type named -v it shows you BIND 9 version.
But when I try your solution Kristian: systemctl enable bind9.service
I get this error:
Failed to enable unit: Unit file bind9.service does not exist.
 
For some weird reason, even though named is not installed as a service on Ubuntu Focal, when you type named -v it shows you BIND 9 version.
I'm not sure what Ubuntu calls the service, but I'm pretty sure the package is called bind9 at least, assuming the package is installed by CustomBuild, and it's not compiled. Double check: dpkg -l | grep bind9. If it's installed, the service should be called either named or bind9. If the package is not installed, it's possible CustomBuild has compiled it, in which case I'm guessing the service is called named.
 
Bash:
ii  bind9                                1:9.16.1-0ubuntu2.9                   amd64        Internet Domain Name Server
ii  bind9-dnsutils                       1:9.16.1-0ubuntu2.9                   amd64        Clients provided with BIND 9
ii  bind9-host                           1:9.16.1-0ubuntu2.9                   amd64        DNS Lookup Utility
ii  bind9-libs:amd64                     1:9.16.1-0ubuntu2.9                   amd64        Shared Libraries used by BIND 9
ii  bind9-utils                          1:9.16.1-0ubuntu2.9                   amd64        Utilities for BIND 9
ii  dnsutils                             1:9.16.1-0ubuntu2.9                   all          Transitional package for bind9-dnsutils

Also did sudo dpkg -s bind9:
Bash:
Package: bind9
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 868
Maintainer: Ubuntu Developers <[email protected]>
Architecture: amd64
Version: 1:9.16.1-0ubuntu2.9
Replaces: bind (<< 1:9.13.6~)
Depends: adduser, bind9-libs (= 1:9.16.1-0ubuntu2.9), bind9-utils (= 1:9.16.1-0ubuntu2.9), debconf | debconf-2.0, dns-root-data, lsb-base (>= 3.2-14), iproute2, netbase, libc6 (>= 2.7), libcap2 (>= 1:2.10), libjson-c4 (>= 0.13.1), liblmdb0 (>= 0.9.7), libmaxminddb0 (>= 1.3.0), libssl1.1 (>= 1.1.0), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4)
Pre-Depends: init-system-helpers (>= 1.54~)
Suggests: bind-doc, dnsutils, resolvconf, ufw
Breaks: bind (<< 1:9.13.6~)
Conffiles:
 /etc/apparmor.d/usr.sbin.named 34502426376b676b22e36c63d3cbb5a9
 /etc/bind/bind.keys b6d32dd16ced89ad2b0fdb8f3bee7aab
 /etc/bind/db.0 8aba258068c8c60a7ade3952a285f57d
 /etc/bind/db.127 64f5cf50e8d8192109dad43b779e5e36
 /etc/bind/db.255 8aba258068c8c60a7ade3952a285f57d
 /etc/bind/db.empty 4e7a0ebff9a8936e5a72ec18c0c49214
 /etc/bind/db.local e5d27ead2d238928a08d33c7a7333477
 /etc/bind/named.conf 32be43ecfcb37f69bf967c15c368e184
 /etc/bind/named.conf.default-zones 9fbdc4657090b3b2a45f7e7b8468cf96
 /etc/bind/named.conf.local fb15a27656eafd86ff870effabc72f1e
 /etc/bind/named.conf.options 642e258554b7bd95f4fc71062ca82101
 /etc/bind/zones.rfc1918 d04252b4368b66e28376f92613842888
 /etc/default/named 0fcf4e70d1d3811d13a1f7b52fd5e384
 /etc/init.d/named 2f033c8e309de34d6ae67fca64292598
 /etc/insserv.conf.d/bind9 2f36010c32cff9acc445bb9b577aecf7
 /etc/network/if-down.d/bind9 dd11845d860cd2e30dce8556aa478eb2
 /etc/network/if-up.d/bind9 dd11845d860cd2e30dce8556aa478eb2
 /etc/ppp/ip-down.d/bind9 dd11845d860cd2e30dce8556aa478eb2
 /etc/ppp/ip-up.d/bind9 dd11845d860cd2e30dce8556aa478eb2
 /etc/ufw/applications.d/bind9 ac2316819866611a68b976db9125c9a7
Description: Internet Domain Name Server
 The Berkeley Internet Name Domain (BIND 9) implements an Internet domain
 name server.  BIND 9 is the most widely-used name server software on the
 Internet, and is supported by the Internet Software Consortium, www.isc.org.
 .
 This package provides the server and related configuration files.
Homepage: https://www.isc.org/downloads/bind/
Original-Maintainer: Debian DNS Team <[email protected]>

Not sure what to make of it.
Tried everything I found on the forum.
Still get the error:

1639042621400.png
 
The init script is called named at least, so the (systemd) service might be as well. Did you try service named start?
 
The init script is called named at least, so the (systemd) service might be as well. Did you try service named start?
Yes:


Bash:
Failed to start named.service: Unit named.service has a bad unit file setting.
See system logs and 'systemctl status named.service' for details.
 
Bash:
Failed to start named.service: Unit named.service has a bad unit file setting.
See system logs and 'systemctl status named.service' for details.
This message suggests two things to do. Only you can do those things. After doing them, post again with any further questions you may have.

I would also recommend you stick to one thread on this forum for your problem. It seems you have posted about this problem multiple places.
 
It's maybe better to keep it in this thread then.

I just vind this odd
/etc/default/named 0fcf4e70d1d3811d13a1f7b52fd5e384
/etc/init.d/named 2f033c8e309de34d6ae67fca64292598
So what now, has Debian again changed the service name? First it was bind9 in systemd, then it was bind9 in /etc/init.d and now they changed it to /etc/init.d/named?

Maybe this can be a temp solution by creating a symlink from this named to the bind9 name (just try, you can always remove it).
ln -s /etc/init.d/named /etc/init.d/bind9

Can you also post the content of the named.service file?
Because that is looking for a bad unit file, maybe we can discouver which unit file it's looking for.

Edit: change the symlink, made a booboo, now it's good. :)
 
This message suggests two things to do. Only you can do those things. After doing them, post again with any further questions you may have.

I would also recommend you stick to one thread on this forum for your problem. It seems you have posted about this problem multiple places.
I only replied with relevant information on posts that were already there. I have no posts.
 
It's maybe better to keep it in this thread then.

I just vind this odd

So what now, has Debian again changed the service name? First it was bind9 in systemd, then it was bind9 in /etc/init.d and now they changed it to /etc/init.d/named?

Maybe this can be a temp solution by creating a symlink from this named to the bind9 name (just try, you can always remove it).
ln -s /etc/init.d/named /etc/init.d/bind9

Can you also post the content of the named.service file?
Because that is looking for a bad unit file, maybe we can discouver which unit file it's looking for.

Edit: change the symlink, made a booboo, now it's good. :)
Tried
Code:
ln -s /etc/init.d/named /etc/init.d/bind9
and restarted DA, still get the error.
Yes I verified it:
lrwxrwxrwx 1 root root 17 Dec 9 14:51 /etc/init.d/bind9 -> /etc/init.d/named

Should I remove it now?
Any other ideas?
 
Back
Top