nsd
nsd copied to clipboard
catz: <defunct> processes then under load & forking
I'm testing the catalog zones branch https://github.com/NLnetLabs/nsd/pull/294
I've been running it on smaller name servers and it works apart from earlier reported issue https://github.com/NLnetLabs/nsd/issues/288.
A new thing I've discovered is that then NSD is put under production load and it forks very frequently due to zone updates, the catalog zones branch of NSD gets
nsd 663232 1 0 10:52 ? 00:00:22 /usr/sbin/nsd -d -P
nsd 663233 663232 81 10:52 ? 00:47:23 /usr/sbin/nsd -d -P
nsd 869581 663233 5 11:51 ? 00:00:00 [nsd: server 1] <defunct>
nsd 869582 663233 5 11:51 ? 00:00:00 [nsd: server 2] <defunct>
nsd 869584 663233 5 11:51 ? 00:00:00 [nsd: server 3] <defunct>
nsd 869585 663233 8 11:51 ? 00:00:00 [nsd: server 4] <defunct>
nsd 869586 663233 6 11:51 ? 00:00:00 [nsd: server 5] <defunct>
nsd 869588 663233 9 11:51 ? 00:00:00 [nsd: server 6] <defunct>
nsd 869589 663233 5 11:51 ? 00:00:00 [nsd: server 7] <defunct>
nsd 869590 663233 5 11:51 ? 00:00:00 [nsd: server 8] <defunct>
nsd 869591 663233 5 11:51 ? 00:00:00 [nsd: server 9] <defunct>
nsd 869592 663233 5 11:51 ? 00:00:00 [nsd: server 10] <defunct>
nsd 869602 663233 5 11:51 ? 00:00:00 [nsd: server 11] <defunct>
nsd 869606 663233 11 11:51 ? 00:00:00 [nsd: server 12] <defunct>
nsd 869607 663233 16 11:51 ? 00:00:00 [nsd: server 13] <defunct>
nsd 869608 663233 10 11:51 ? 00:00:00 [nsd: server 14] <defunct>
nsd 869609 663233 11 11:51 ? 00:00:00 [nsd: server 15] <defunct>
nsd 869610 663233 11 11:51 ? 00:00:00 [nsd: server 16] <defunct>
nsd 869611 663233 11 11:51 ? 00:00:00 [nsd: server 17] <defunct>
nsd 869612 663233 10 11:51 ? 00:00:00 [nsd: server 18] <defunct>
nsd 869613 663233 11 11:51 ? 00:00:00 [nsd: server 19] <defunct>
nsd 869614 663233 11 11:51 ? 00:00:00 [nsd: server 20] <defunct>
nsd 869615 663233 11 11:51 ? 00:00:00 [nsd: server 21] <defunct>
nsd 869616 663233 22 11:51 ? 00:00:00 [nsd: server 22] <defunct>
nsd 869617 663233 10 11:51 ? 00:00:00 [nsd: server 23] <defunct>
nsd 869618 663233 11 11:51 ? 00:00:00 [nsd: server 24] <defunct>
nsd 869619 663233 9 11:51 ? 00:00:00 [nsd: main] <defunct>
nsd 869620 663233 2 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869621 663233 1 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869622 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869623 663233 5 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869624 663233 1 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869625 663233 3 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869626 663233 1 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869627 663233 1 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869628 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869629 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869657 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869671 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869678 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869679 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869680 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869681 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869696 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869699 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869701 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869707 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869710 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869712 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869713 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869714 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869717 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869719 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869720 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869721 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
nsd 869726 663233 0 11:51 ? 00:00:00 /usr/sbin/nsd -d -P
I can't find any hints in the log then using verbosity 3, but NSD doesn't seem to suffer from an operational POV. It's siblings (name servers) that are running the "regular" branch haven't showed this behavior at all, so I thought it would be good to mention this for the catalog zones developer(s).