pierre-philipp braun
2019-May-12 12:30 UTC
[nsd-users] problems sending reload xfrdtomain: Broken pipe
Yolo
I've compiled 4.1.27 on netbsd-current (8.99) without any issue, then
configured it with a single forward zone and I always end-up with this error no
matter what.
nsd[22124]: nsd starting (NSD 4.1.27)
nsd[22124]: ...stale pid file from process 28114
nsd[22124]: setup SSL certificates
nsd[22673]: /nsd.db: not cleanly closed 0
nsd[22673]: can not use /nsd.db, will create anew
nsd[22673]: zone nethence.com read with success
nsd[22673]: zone nethence.com written to db
nsd[16988]: problems sending reload xfrdtomain: Broken pipe
nsd[16988]: did not get start signal from main
Same goes with remote-control enabled
Same goes with more advanced chroot pathes
I found the previous thread from 2014 on that matter but getting rid of
/var/db/nsd/nsd.db (nor /var/run/nsd/nsd.pid) beforehand does not help. My case
seems different.
What is xfrdtomain expecting, is it creating a socket file? And why is this
called anyway, as the following MWE does NOT mandate any zone transfers to
happen? What could be causing the problem? How to debug this?
server:
verbosity: 3
remote-control:
control-enable: no
zone:
name: "nethence.com"
zonefile: "%s.db"
I also looked at ktrace/kdump (netbsd's equivalent for strace) and I see
some
12105 1 nsd RET setsockopt -1 errno 55 No buffer space available
Other daemon live fine on this system so I doubt this is a netbsd bug (although
that's current)
And thank you for the nice piece of software
Wouter Wijngaards
2019-May-13 07:08 UTC
[nsd-users] problems sending reload xfrdtomain: Broken pipe
Hi Pierre-Philipp, Setting database: "" in the configuration may help. But regardless, I would like to reproduce the error. If you could (off-list, privately) send me the zonefile? My guess is that the content of the zonefile somehow gives a problem, if the below configuration causes the crash. About debug info, NSD has the option to emit more debug information, with -V 5. If compiled with debug enabled, also -F -1 -L 2 can emit even more debug information (per-packet and per-zone-update, so that is a lot). Best regards, Wouter On 5/12/19 2:30 PM, pierre-philipp braun wrote:> Yolo > > I've compiled 4.1.27 on netbsd-current (8.99) without any issue, then configured it with a single forward zone and I always end-up with this error no matter what. > > nsd[22124]: nsd starting (NSD 4.1.27) > nsd[22124]: ...stale pid file from process 28114 > nsd[22124]: setup SSL certificates > nsd[22673]: /nsd.db: not cleanly closed 0 > nsd[22673]: can not use /nsd.db, will create anew > nsd[22673]: zone nethence.com read with success > nsd[22673]: zone nethence.com written to db > nsd[16988]: problems sending reload xfrdtomain: Broken pipe > nsd[16988]: did not get start signal from main > > Same goes with remote-control enabled > Same goes with more advanced chroot pathes > > I found the previous thread from 2014 on that matter but getting rid of /var/db/nsd/nsd.db (nor /var/run/nsd/nsd.pid) beforehand does not help. My case seems different. > > What is xfrdtomain expecting, is it creating a socket file? And why is this called anyway, as the following MWE does NOT mandate any zone transfers to happen? What could be causing the problem? How to debug this? > > server: > verbosity: 3 > > remote-control: > control-enable: no > > zone: > name: "nethence.com" > zonefile: "%s.db" > > > I also looked at ktrace/kdump (netbsd's equivalent for strace) and I see some > > 12105 1 nsd RET setsockopt -1 errno 55 No buffer space available > > Other daemon live fine on this system so I doubt this is a netbsd bug (although that's current) > > And thank you for the nice piece of software > > _______________________________________________ > nsd-users mailing list > nsd-users at NLnetLabs.nl > https://open.nlnetlabs.nl/mailman/listinfo/nsd-users >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20190513/dadd510a/attachment.bin>