Dear Debian maintainers,

After installing the recent security update
	bind9:amd64 (1:9.18.33-1~deb12u2 → 1:9.18.41-1~deb12u1)
I noticed today the named service no longer starts correctly. systemd restarts it continuously (about 900 times per day).

From journalctl:
	[...]
	named.service: start operation timed out. Terminating.
	[...]
	named.service: Failed with result 'timeout'.

Starting named manually works as flawless:
	/usr/sbin/named -u bind -t /var/lib/bind -n 3

The issue seems related to the systemd unit configuration. After adding the following options under [Service], the service starts normally:
	RestartSec=10
	TimeoutStartSec=300
‥and removing the line (done accidently, when debugging):
	Type=notify

With all these three changes the service runs at my side without an issue.

Best regards,
	Klaus Singvogel.

Please don't abuse the severities. This is at most important as it is not broken for everyone.

The bugreport doesn't contain any actionable information. No logs, no nothing. It looks like
the systemd notify is not working, but the question is why it does not work just for you.

Is there anything unusual about your configuration – I mean what are the things that have
been changed by you as compared to the default configuration? Are you running with chroot
for example?

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Hello,

Thank you for your response.

I agree, the severity can be lowered if this is not generally reproducible.

Regarding configuration:
- The system is using the default bind9 setup on Debian 12 (bookworm), installed via apt, no custom build
- The service is running with the default chroot directory /var/lib/bind, as defined by the package
- The options in /etc/default/named are (nothing more):
	RESOLVCONF=no
	OPTIONS="-u bind -t /var/lib/bind -n 3"
- I don't want to reveal my domains publicly by sending /etc/bind/named.conf.default-zones
- My options in /etc/bind/named.conf.options are:
	options {
		recursion yes;
		allow-recursion { any; };

		forwarders {
			208.67.222.222;         # OpenDNS
			208.67.220.220;         # OpenDNS
			8.8.8.8;                # Google
			9.9.9.10;               # Quad9
		};

		dnssec-validation no;

		listen-on { any; };
		listen-on-v6 { any; };
	};
- There are no other local modifications to the bind9 configuration or service files.

Before the security update, the service had been running without any issues for several months. After applying the update, the repeated restarts started immediately.

Once I added the timeout settings (RestartSec=10 and TimeoutStartSec=300) to the systemd unit, the service has been running normally again without further problems.

It seems that the named service should be able to start and run correctly even with the default systemd configuration. On my system, the issue only appeared after the security update, and adjusting the timeout values resolved the problem.

Best regards,
	Klaus.

Well, that explains it. Seems like the debian/bind9.NEWS didn't get into the updated package:

  * 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

I'll pull this into the next security update.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Thank you for the explanation and the suggested fix. I have tested it on my system, and the service now starts and runs normally.

I appreciate your work on including this in the next security update.

Best regards,
	Klaus.