NSD stops forking with newer zone data

NSD
1

Hello,

It seems our NSD secondary has triggered some sort of intermittent bug
After several weeks/months of running nsd stops forking with the new zone data.

A manual nsd-control transfer or even nsd-control force_transfer won’t work, only restart of nsd solves the problem.
The only “hint” I’ve found is that the nsd xfrd messages stops appearing in the logs (while the notify messages keeps coming).

I’ve put the details in this issue https://github.com/NLnetLabs/nsd/issues/417

Re,
/P

2

hi,

3

Thanks Fredrik,

And yes Tamás, this is indeed quite similar to your issue. I was hoping that the notifies directly to the transfer daemon in 4.11 would resolve this, but there may be another cause.

The issue is my first priority with NSD now. I'm planning to add some additional monitoring and watchdogs for the several stages of the reload process, that can also trigger log events when they take longer (logging which stage of the reload process took how much time so far). I will merge the two issues, because they are indeed quite similar, and report on this work there.

Regards,

-- Willem

4

Hi,

hi,

Hello,
It seems our NSD secondary has triggered some sort of intermittent bug
After several weeks/months of running nsd stops forking with the new zone data.
A manual nsd-control transfer or even nsd-control force_transfer won’t work, only restart of nsd solves the problem.
The only “hint” I’ve found is that the nsd xfrd messages stops appearing in the logs (while the notify messages keeps coming).
I’ve put the details in this issue https://github.com/NLnetLabs/nsd/issues/417

It seems somewhat similar to the issue I have experienced:
https://github.com/NLnetLabs/nsd/issues/338

The symptoms are similar, but we don’t have verification configured on this host, so I don’t think it’s the same issue.

in my case it recovered on its own.

Only a restart makes it recover in our case.

Re,
/P