named.service or bind9.service or both?

[Jesper Dybdal]

I'm running Buster.  I then had a problem with BIND and DNSSEC, so I
upgraded my bind9 package to the one in buster-backports.

But it seems that this has involved a partial rename of the systemd unit
from bind9 to named.  So I now have two almost equal systemd units.  And
named.service includes an "Alias=bind9.service" line, whose exact
meaning I don't understand.  And named.service includes a "Wants" and a
"Before" line that bind9.service does not include (details below).

Searching for files named {named,bind9}.service gives:
 28706180      0 -rw-r--r--   1 root     root            0 Apr  3 2016
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service
   262273      4 -rw-r--r--   1 root     root          364 Mar 20 2022
/lib/systemd/system/named.service
 28970007      0 lrwxrwxrwx   1 root     root           33 Jan 15 15:42
/etc/systemd/system/multi-user.target.wants/named.service ->
/lib/systemd/system/named.service
 28968976      0 lrwxrwxrwx   1 root     root           33 Apr 10 2016
/etc/systemd/system/multi-user.target.wants/bind9.service ->
/etc/systemd/system/bind9.service
 28969163      4 -rw-r--r--   1 root     root          255 Jun  2 2016
/etc/systemd/system/bind9.service

I suspect that the bind9 service ought to be removed.  Is that correct? 
And I suspect that the first thing to do is "systemctl disable bind9" -
is that right?  And then perhaps delete the bind9.service file?  But
what about the "Alias=" line in named.service - does that work if
bind9.service is removed?

Right now the system is running and the backports nameserver works fine,
but I wonder if anything will go wrong on the next reboot. And I would
like to clean up the situation in a way that will not give problems when
I later upgrade the system to Bullseye.  How do I do that?

Here are the unit files and unit statuses:

> root@nuser:~# systemctl cat bind9
> # /etc/systemd/system/bind9.service
> [Unit]
> Description=BIND Domain Name Server
> Documentation=man:named(8)
> After=network.target
>
> [Service]
> ExecStart=/usr/sbin/named -f -4 -u bind -t /etc/bind
> ExecReload=/usr/sbin/rndc reload
> ExecStop=/usr/sbin/rndc stop
>
> [Install]
> WantedBy=multi-user.target

> root@nuser:~# systemctl cat named
> # /lib/systemd/system/named.service
> [Unit]
> Description=BIND Domain Name Server
> Documentation=man:named(8)
> After=network.target
> Wants=nss-lookup.target
> Before=nss-lookup.target
>
> [Service]
> EnvironmentFile=-/etc/default/named
> ExecStart=/usr/sbin/named -f $OPTIONS
> ExecReload=/usr/sbin/rndc reload
> ExecStop=/usr/sbin/rndc stop
> Restart=on-failure
>
> [Install]
> WantedBy=multi-user.target
> Alias=bind9.service

> root@nuser:~# systemctl status bind9
> ● bind9.service - BIND Domain Name Server
>    Loaded: loaded (/etc/systemd/system/bind9.service; enabled; vendor
> preset: enabled)
>    Active: active (running) since Sun 2023-01-15 15:47:13 CET; 18h ago
>      Docs: man:named(8)
>  Main PID: 2349 (named)
>     Tasks: 8 (limit: 4691)
>    Memory: 47.0M
>    CGroup: /system.slice/bind9.service
>            └─2349 /usr/sbin/named -f -4 -u bind -t /etc/bind

> root@nuser:~# systemctl status named
> ● named.service - BIND Domain Name Server
>    Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor
> preset: enabled)
>    Active: failed (Result: exit-code) since Sun 2023-01-15 15:42:14
> CET; 18h ago
>      Docs: man:named(8)
>   Process: 1412 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited,
> status=1/FAILURE)
>  Main PID: 1412 (code=exited, status=1/FAILURE)

--
Jesper Dybdal
https://www.dybdal.dk

[Greg Wooledge]

On Mon, Jan 16, 2023 at 10:42:35AM +0100, Jesper Dybdal wrote:
>  28969163      4 -rw-r--r--   1 root     root          255 Jun  2 2016
> /etc/systemd/system/bind9.service
>
> I suspect that the bind9 service ought to be removed.  Is that correct?

It looks like you (or someone acting on your behalf) created a local
instance of this bind9.service file, over 6 years ago. Perhaps you
had been instructed that if you wanted to make changes to a unit file,
you were supposed to copy the whole thing to /etc/systemd/system/
and then edit that copy. (That is indeed ONE possible way to go about
it, but not the best way, usually.)

In any case, yeah, I'd get rid of that. Maybe move it to /root/ in case
you want to refer to it in the future, or whatever. Afterward, do a
"systemctl daemon-reload".

[Jesper Dybdal]

On 2023-01-16 13:36, Greg Wooledge wrote:
> On Mon, Jan 16, 2023 at 10:42:35AM +0100, Jesper Dybdal wrote:
>>  28969163      4 -rw-r--r--   1 root     root          255 Jun  2 2016
>> /etc/systemd/system/bind9.service
>>
>> I suspect that the bind9 service ought to be removed.  Is that correct?
> It looks like you (or someone acting on your behalf) created a local
> instance of this bind9.service file, over 6 years ago.

I now remember that I did that - at a time when I was completely new to
Debian.  Probably because I followed the instructions at
https://wiki.debian.org/Bind9#Debian_Jessie_and_later

> Perhaps you
> had been instructed that if you wanted to make changes to a unit file,
> you were supposed to copy the whole thing to /etc/systemd/system/
> and then edit that copy. (That is indeed ONE possible way to go about
> it, but not the best way, usually.)

Indeed it is not.  It seems I didn't know that at the time.

> In any case, yeah, I'd get rid of that. Maybe move it to /root/ in case
> you want to refer to it in the future, or whatever. Afterward, do a
> "systemctl daemon-reload".

I'll do that.  Should I then also remove the "Alias=bind9.service" line
from named.service?

And thanks for your help!

[Greg Wooledge]

On Mon, Jan 16, 2023 at 03:51:52PM +0100, Jesper Dybdal wrote:
> I'll do that.  Should I then also remove the "Alias=bind9.service" line from
> named.service?

If Debian put it there, then no. Leave it alone. It's probably just
a backward compatibility shim, from when the service name used to be
"bind9" instead of "named", but there's no telling how many other
packages might be relying on that shim.

[Jesper Dybdal]

On 2023-01-16 13:36, Greg Wooledge wrote:

> On Mon, Jan 16, 2023 at 10:42:35AM +0100, Jesper Dybdal wrote:
>>  28969163      4 -rw-r--r--   1 root     root          255 Jun  2 2016
>> /etc/systemd/system/bind9.service
>>
>> I suspect that the bind9 service ought to be removed.  Is that correct?

> ...

> In any case, yeah, I'd get rid of that. Maybe move it to /root/ in case
> you want to refer to it in the future, or whatever. Afterward, do a
> "systemctl daemon-reload".
>

I have now, in order:
* Disabled bind9.service
* Corrected /etc/default/named so the named service can start (it was
missing the chroot)
* Stopped bind9.service
* Started named.service and checked that named i actually running
* Deleted /etc/systemd/system/bind9.service
* Deleted /etc/default/bind9
* Run systemctl daemon-reload
* Checked that "systemctl restart named.service" works

That leaves one file in the system with the name "bind9.service":
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service
Can I safely delete that one (I suspect so)?  Will it be a problem
during reboot if I leave it?

Thanks!

[Jeffrey Walton]

if you are manually deleting the bind9 gear, you may as well go full
in. You can't get half pregnant.

Find the bind9 artifacts left on the system:

find /etc -name 'bind9*'

Then whack it:

find /etc -name 'bind9*' -exec rm -f {} \;

Jeff

[Greg Wooledge]

On Wed, Jan 18, 2023 at 12:25:03PM +0100, Jesper Dybdal wrote:
> I have now, in order:
> * Disabled bind9.service
> * Corrected /etc/default/named so the named service can start (it was
> missing the chroot)
> * Stopped bind9.service
> * Started named.service and checked that named i actually running
> * Deleted /etc/systemd/system/bind9.service
> * Deleted /etc/default/bind9
> * Run systemctl daemon-reload
> * Checked that "systemctl restart named.service" works
>
> That leaves one file in the system with the name "bind9.service":
> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service
> Can I safely delete that one (I suspect so)?  Will it be a problem during
> reboot if I leave it?

I've never had to worry about the files in there. I suspect it'll
get removed when you reboot, if you don't remove it yourself. In any
case, the files in that directory are all 0 bytes long -- it's just
their names that matter. So replacing it would be simple, if for some
reason removing it causes an issue. (Which I seriously doubt it will.)

[Jesper Dybdal]

It turns out that in /etc/network there are some scripts to be run on
interface up/down, and some of those scripts have "bind9" names. And the
scripts seem like generic BIND-related stuff (reconfig on interface
up/down), not particularly related to the sustemd unit. I've let them
survive for the time being.

Thanks for your help!

[Jesper Dybdal]

On 2023-01-18 13:55, Greg Wooledge wrote:
> On Wed, Jan 18, 2023 at 12:25:03PM +0100, Jesper Dybdal wrote:
>> That leaves one file in the system with the name "bind9.service":
>> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service
>> Can I safely delete that one (I suspect so)?  Will it be a problem during
>> reboot if I leave it?
> I've never had to worry about the files in there. I suspect it'll
> get removed when you reboot, if you don't remove it yourself

I've deleted it now.  And some day soon I'll reboot and see what happens.

Thanks again for your help!