Systemd integration test

Hi,

Recently I have written systemd integration code for NSD, based on the
code that was contributed to Unbound previously. This code can pick up
sockets (systemds socket activation) for a port without having
widespread port permissions, and can signal systemd that the server is
ready (sd_notify).

But before I could mark the feature as available for general use, I need
to know if it works. I could just mark it experimental and wait for
users that want it to try it. It probably works fine. If there are
users now that would appreciate improved systemd integration for NSD, it
is possible to try out the new features from the code repository.

We normally already wait with rc1 release candidates for maintainer and
release integration, but I felt that with this change, it would be
better to ask beforehand for a more smooth troublefree release process.

The feature is enabled with configure --enable-systemd (needs pkg-config
and libsystemd). Then in nsd.conf set use-systemd: yes. You also need
files for systemd, which I don't really know, but made a guess based on
files contributed to Unbound, they are in NSD's code repository,
nsd.socket and nsd.service in the contrib directory.

Best regards, Wouter

Recently I have written systemd integration code for NSD, based on the
code that was contributed to Unbound previously. This code can pick up
sockets (systemds socket activation) for a port without having
widespread port permissions, and can signal systemd that the server is
ready (sd_notify).

The unbound systemd code caused crashes even when it was disabled in
fedora/rhel. So we decided to not compile the support anymore.

But additionally, socket activation is useful for services that exist
on their own port, which only get used when rarely needed. That is,
as an inetd replacement it is great.

It is not great for a port where several programs might try to grab the
port. On linux systems with qemu/kvm/libvirt we have dnsmasq that needs
to share this space with unbound. Some have unbound + nsd running and
they need to ensure they each grab only some IP addresses port 53.
Making these decisions based on random incoming packets leads to
problems.

For other applications, (like libreswan IKE daemon) I also rejected
socket activation because it simply makes no sense for daemons that are
guaranteed to get started anyway pretty quickly after boot.

Socket activation with systemd is a boot speed up fetish. It makes the
boot appear faster. In most cases other then the rarely used service use
case of inetd started, there is no valid reason for socket activation.

I think adding/enabling socket activation with DNS software is a mistake.

That said, sd_notify is a useful software watchdog device. It would be
nice to be able to support that compile time without making it a package
deal with socket activation. (case in point: libreswan supports sd_notify,
but not socket activation)

But before I could mark the feature as available for general use, I need
to know if it works.

Earlier attempst to compile in support but leave it disabled for unbound
(for the above stated reasons) caused crashes and we ended up disabling
it at compile time. If this code is that similar to unbound, I would
also not enable it for nsd at compile time. It would be sad if that
means missing out on the software watchdog sd_notify.

Paul

Hi Paul,

Recently I have written systemd integration code for NSD, based on the
code that was contributed to Unbound previously. This code can pick up
sockets (systemds socket activation) for a port without having
widespread port permissions, and can signal systemd that the server is
ready (sd_notify).

The unbound systemd code caused crashes even when it was disabled in
fedora/rhel. So we decided to not compile the support anymore.

Could the following patch (for Unbound) remove the failure? I notice
that it did not check the entire address and thus the activated sockets
could get wrong, this patch rectifies that issue. But I don't really
see how that could have caused crashes. So perhaps all it does it
shuffle the file descriptors slightly without fixing the crash issue.

However, I can remove the socket activation (from Unbound and NSD), and
then have sd_notify support that could be very useful to have for
systemd users? If socket activation did not cause issues, I would not
favor its removal.

Index: services/listen_dnsport.c