Bind9 Installation fails using Proxmox 9.0

P

PT400C

Active Member
May 30, 2018
19
0
41
Germany
Installing Bind9 using Proxmox 9.0 (Trixie) fails with the following message:

Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

The entire log is:

Code: 
Installing:                    
  bind9

Installing dependencies:
  bind9-utils  dns-root-data

Suggested packages:
  bind9-doc  resolvconf  ufw

Summary:
  Upgrading: 0, Installing: 3, Removing: 0, Not Upgrading: 0
  Download size: 442 kB
  Space needed: 1,672 kB / 1,831 GB available

Continue? [Y/n] y
Get:1 http://deb.debian.org/debian trixie/main amd64 bind9-utils amd64 1:9.20.11-4 [183 kB]
Get:2 http://deb.debian.org/debian trixie/main amd64 dns-root-data all 2024071801 [5,672 B]
Get:3 http://deb.debian.org/debian trixie/main amd64 bind9 amd64 1:9.20.11-4 [254 kB]
Fetched 442 kB in 0s (10.2 MB/s)
Selecting previously unselected package bind9-utils.
(Reading database ... 50144 files and directories currently installed.)
Preparing to unpack .../bind9-utils_1%3a9.20.11-4_amd64.deb ...
Unpacking bind9-utils (1:9.20.11-4) ...
Selecting previously unselected package dns-root-data.
Preparing to unpack .../dns-root-data_2024071801_all.deb ...
Unpacking dns-root-data (2024071801) ...
Selecting previously unselected package bind9.
Preparing to unpack .../bind9_1%3a9.20.11-4_amd64.deb ...
Unpacking bind9 (1:9.20.11-4) ...
Setting up dns-root-data (2024071801) ...
Setting up bind9-utils (1:9.20.11-4) ...
Setting up bind9 (1:9.20.11-4) ...
wrote key file "/etc/bind/rndc.key"
named-resolvconf.service is a disabled or a static unit, not starting it.
Created symlink '/etc/systemd/system/bind9.service' → '/usr/lib/systemd/system/named.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/named.service' → '/usr/lib/systemd/system/named.service'.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.
Processing triggers for man-db (2.13.1-1) ...

Checking the status of the service shows this: Sep 09 11:30:51 server69 named[1839]: named: failed to connect to notification socket '/run/systemd/notify': permission denied

Any idea what might be going on here? We're rocking this version of Proxmox: pve-manager/9.0.6/49c767b70aeb6648 (running kernel: 6.14.11-1-pve)

Thanks in advance

PT400C
 
Last edited:
Hi all, in the APT List changes email the Debian 13 installer sends to the root user it mentions that the named Unit file must be modified ... See ...

* Since Debian bookworm, the BIND 9 has support for Type=notify
reporting in the systemd unit file. Because of that, running
named in the chroot requires the chroot to have the sd_notify
socket available.

One possible solution is to create the systemd unit override
and add ad bind-mount for the notify socket:

[Service]
BindPaths=/run/systemd/notify:<chroot_path>/run/systemd/notify

In my setup , already a PVE 8 with an installed BIND9 package, I have the same problem when I upgraded to PVE 9 Debian 9 and now the named service shows the exact same notify error. I try to follow the before mentioned changes by creating the systemd override file by using the systemctl edit named.service command but in my case named is not really chrooted so there is no chroot directory anywhere so I have no idea what to do then. All my 3 PVE hosts have a BIND9 DNS server installed and all did or do the same thing but I had other Debian 12 servers on several clouds and on premises , all running a BIND9 DNS Server, all as VM's or Proxmox guests and in those cases the upgraded went smooth and named service does not have any error neither it is still activating or restarts every minute.

Should I jail or chroot the named service?

Should we Proxmox users wait for a future Proxmox or Debian or BIND9 update to fix this?

Any help will be appreciated and Thanks in advance,
Juan J. Fernández
 
Hi, I just compared the output of command

systemctl show named.service

And I noticed that on the Debian 13 TRIXIE were BIND9 or named service works perfectly without that status error THE NAMED UNIT does not show that BindPaths I mentioned earlier from the APT Listchanges email. See ...

RestrictRealtime=no
RestrictSUIDSGID=no
RestrictNamespaces=no
MountAPIVFS=no
BindLogSockets=no
KeyringMode=private

I did the same systemctl show named.service command .....
However on my 3 PVE hosts that are 3 BIND9 DNS Servers I AADITIONALLY SEE the BindPaths=/run/systemd/.... Directive Added . See ...

RestrictRealtime=no
RestrictSUIDSGID=no
RestrictNamespaces=no
BindPaths=/run/systemd/notify:/run/systemd/notify:rbind
MountAPIVFS=no
BindLogSockets=no
KeyringMode=private

So , I decided to remove that BindPaths= directive by simply systemctl edit named.service to create an override file with a blank BindPaths= ... BUT THAT FAILS so named does not restart in that case .

So I did a REVERT of the override with systemctl revert named.service and NOW I DONT SEE the BindPaths directive anymore but still same thing as after the Debian 13 PVE 9.0 Upgrade, it shows that systemd/notify error on systemctl status named.service and it says Activating ....

Does anyone know why on the normal Debian 13 server it does not show the BindPaths= thingy and NAMED works perfectly but on PVE 9.0 it shows the BindPaths= but NAMED does not fully activate o start?

As always , any help will be appreciated and thanks in advance.
Juan
 
You must log in or register to reply here.
Top Bottom