Re: named.service or bind9.service or both?
On 2023-01-18 13:39, Jeffrey Walton wrote: On Wed, Jan 18, 2023 at 6:25 AM 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? if you are manually deleting the bind9 gear, you may as well go full in. You can't get half pregnant. 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 https://www.dybdal.dk
Re: named.service or bind9.service or both?
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! -- Jesper Dybdal https://www.dybdal.dk
Re: named.service or bind9.service or both?
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.)
Re: named.service or bind9.service or both?
On Wed, Jan 18, 2023 at 6:25 AM Jesper Dybdal wrote:
>
>
> 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?
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
Re: named.service or bind9.service or both?
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! -- Jesper Dybdal https://www.dybdal.dk
Re: named.service or bind9.service or both?
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.
Re: named.service or bind9.service or both?
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! -- Jesper Dybdal https://www.dybdal.dk
Re: named.service or bind9.service or both?
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".
named.service or bind9.service or both?
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
