I have a laptop computer running OpenBSD 5.8 configured to use unbound
version 1.5.4 and ntpd but which does not have any network interface
configured by default (except lo0, obviously) since which interface
needs to be configured and how depends on where I'm using the
computer.
After booting, unbound and ntpd both start without problem. Then ntpd
automatically starts trying to contact NTP servers from pool.ntp.org,
which triggers DNS queries. In turn unbound tries to contact root DNS
servers and fails since no network interface is configured yet.
Unbound then logs messages to syslog:
Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: sendto failed: Can't assign requested address
Jan 14 10:07:58 mycomputer unbound: [2824:0] notice: remote address is 192.5.5.241 port 53
The problem is that unbound generates such a pair of messages up to 20
times for each root server! That's 2 lines * 20 times * 13 root
servers = 520 lines that end up going to syslog. Then 15 seconds
later ntpd tries again and you get another 520 lines, and so on. This
continues until a network interface is configured. The result is that
in three days I accumulated over 16000 lines of log messages like the
ones above...
For now I've simply disabled both unbound and ntpd at boot and
modified some scripts so that they are only started after a network
interface has been configured, but is there a way to make unbound more
quiet (short of sending the log messages to /dev/null)?
Or maybe change unbound's code to replace all those superfluous log
messages with a single "all DNS root servers are unreachable" message?
Philippe Meunier via Unbound-users <unbound-users@unbound.net> writes:
After booting, unbound and ntpd both start without problem. Then ntpd
automatically starts trying to contact NTP servers from pool.ntp.org,
which triggers DNS queries. In turn unbound tries to contact root DNS
servers and fails since no network interface is configured yet.
That shouldn't happen. OpenBSD's /etc/rc doesn't start unbound and ntpd
until after /etc/netstart, which configures your network interfaces.
The order is roughly pf (stub ruleset) - netstart - pf (real ruleset) -
early daemons (including unbound and ntpd) - ipsec - rpc, nis and nfs -
everything else.
That shouldn't happen. OpenBSD's /etc/rc doesn't start unbound and ntpd
until after /etc/netstart, which configures your network interfaces.
Except when there's no hostname.if(5) file to configure any interface
automatically, because it's a laptop computer and which interface
needs to be configured and how depends on where I'm using the
computer.
I ended up modifying some scripts so that unbound and ntpd are only
started after I've manually configured a network interface, but the
fact remains that having unbound generate 500+ syslog messages per DNS
request when no network interface is configured is such an overkill
that it verges on the ridiculous...
Philippe Meunier via Unbound-users <unbound-users@unbound.net> writes:
> After booting, unbound and ntpd both start without problem. Then ntpd
> automatically starts trying to contact NTP servers from pool.ntp.org,
> which triggers DNS queries. In turn unbound tries to contact root DNS
> servers and fails since no network interface is configured yet.
That shouldn't happen. OpenBSD's /etc/rc doesn't start unbound and ntpd
until after /etc/netstart, which configures your network interfaces.
The order is roughly pf (stub ruleset) - netstart - pf (real ruleset) -
early daemons (including unbound and ntpd) - ipsec - rpc, nis and nfs -
everything else.
That's irrelevant to the issue Philippe raised. The network is not
always available, no matter how well you configure your system or
engineer your software. The problem here is that when the network is
down, Unbound spews junk to its log as fast as it can.
For years I've seen exactly the same issue as Philippe reported, and I
asked about it on unbound-users a long time ago with no response:
I have more or less worked around it by using daemontools multilog
instead of syslog in order to reliably limit the size and throughput
of the log files and to prevent them from interfering with other logs.
But that's a workaround, not a fix.
While unbound logging has improved a bit since then, I still see far too
many essentially duplicate syslog messages for a single network
unavailable event.
If I need high volume logging for troubleshooting, I'll increase the
logging verbosity. Logging should be something that is helpful, not
something I cringe about.
Taylor R Campbell <campbell+unbound@mumble.net> writes:
That's irrelevant to the issue Philippe raised. The network is not
always available, no matter how well you configure your system or
engineer your software. The problem here is that when the network is
down, Unbound spews junk to its log as fast as it can.
Define "down"; as far as I know, this message should only occur when no
interface is configured at all, or there is a configured interface but
no default route. So a quick hack is to set the initial default gateway
to a random address in 127/8, or set the initial address on one of your
NICs to something in the DHCP fallback range (169.254.0.0/16) and your
initial default gateway to 169.254.0.1.
There was already a similar for for permission denied spammed when the
network was down. But your system returns a different errno in that
situation. I have squelched the errno EADDRNOTAVAIL (Cannot assign
requested address): it is hidden when verbosity is low, visible if you
increase the verbosity. That hopefully keeps Philippe's logs clean.
Thanks! That only partially addresses the problem, though: while
unbound will no longer clutter logs as long as the network is down, it
will still eat CPU -- and it will do so silently now, unless verbose
logs are enabled.
It seems to me that it would be better if Unbound did not busy-wait
for the network to come back up, or for a change in whatever condition
is causing the spew. However, I don't know the code well enough to
suggest any particular changes to accomplish this.