On 27/05/2020 19:02, Simon Deziel wrote:
Hi Simon,
Are you certain of this? I have never seen any errors on my NSD systems.
I reproduced it all in a Debian Buster VM before posting. Are you using
the same systemd unit as Debian Buster's [*] ?
No, I'm running NSD on CentOS 7. I'm not using the unit file from
contrib. I find it a mess. It's trying to enable every possible option
in systemd, without taking care of all the related permission problems
they cause. I build my own packages of NSD, and ship a very simple unit
file with it:
[Unit]
Description=NSD DNS Server
After=network-online.target
[Service]
LimitNOFILE=8192
ExecStart=/usr/sbin/nsd -d
KillMode=process
[Install]
WantedBy=multi-user.target
[Service]
ExecStartPre=-/bin/chown --quiet root:root /var/log/nsd.log
All of this seems to be band-aid upon band-aid of unnecessary hacks.
That's a band-aid indeed. IMHO the proper fix is to be consistent in
handling the file. So either open it as root and not chown it or always
touch it after setuid().
I agree. In order to avoid problems, on my systems, I log to
/var/log/nsd, where that directory is owned by nsd:nsd.
As for the failed unlinking of the pidfile, this is harmless and should
not be logged as a warning. It may already be fixed in newer releases as
it was done with Unbound already.
PID files are so passé! They are irrelevant on systems where daemons are
run under supervisors. I would highly recommend setting "pidfile" to ""
in nsd.conf. This prevents creation of a PID file. Systemd already knows
the PID of the NSD process, and can signal it directly.
Would it make sense to simply ignore the pidfile directive when running
through systemd?
No. I don't like it when software silently does things. Instead, when
package maintainers build NSD for systems with systemd, they should pass
the --with-pidfile="" option to the configure script, so that by
default, NSD doesn't create PID files. If a user still wants a PID file
for some bizarre reason, he can set the "pidfile" option in nsd.conf.
And then deal with the permissions issues himself.
Regards,
Anand
_______________________________________________
nsd-users mailing list
[email protected]
https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
