[Bug 281266] dns/nsd: Versions 4.10.0 and 4.10.1 hanging at startup with high CPU load

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 12 Sep 2024 13:37:58 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281266

--- Comment #5 from regbin <regbinkk+freebsdbugs@gmail.com> ---
Tested with both nsd 4.9.1 and 4.10.1.

nsd-checkconf returns no errors in both versions. nsd-checkzone returns no
error in version 4.9.1, however the same zone files (also the example.com zone)
in version 4.10.1 result in

# nsd-checkzone example.com zones/example.com.zone 
Illegal instruction (core dumped)

Starting the service (version 4.10.1) with 'verbosity: 3' produces only:

[2024-09-12 15:58:57.130] nsd[12883]: notice: nsd starting (NSD 4.10.1)
[2024-09-12 15:58:57.130] nsd[12883]: notice: listen on ip-address ::1@5353
(udp) with server(s): *
[2024-09-12 15:58:57.130] nsd[12883]: notice: listen on ip-address ::1@5353
(tcp) with server(s): *

which doesn't seem very helpful (already tried with all documented verbosity
levels before, hence my comment about no meaningful debugging feedback from the
service).

Manually killing the nsd sub-process (since it's not responding to any
commands) produces:

[2024-09-12 15:59:59.312] nsd[12919]: error: did not get start signal from main

That's how nsd looks like in the process list:

nsd     65678   0.0  0.1 68964  8264  -  IsJ  16:15   0:00.04 nsd: xfrd (nsd)
nsd     65765 100.0  0.3 50168 37384  -  RJ   16:15   0:32.13 - nsd: main (nsd)


I cannot reproduce the problem with the same configuration files on any other
machine either. Is it possible that I've hit some zone-parsing simdzone bug in
combination with old hardware? The problematic nsd instance is running on a
rather old machine:

CPU: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz (2809.95-MHz K8-class CPU)

SSE4.2 instructions seem to be available, AVX2 on the other hand - not. I'm not
aware of the internal nsd/simdzone workings in such a situation and if that
could be the root of the problem at all.

-- 
You are receiving this mail because:
You are the assignee for the bug.