Re: systemd integration test

Wouter Wijngaards <[email protected]> Thu, 12 Jul 2018 12:34:28 +0200
Newsgroups	gmane.network.dns.nsd.general
Message-ID	<[email protected]>
Hi Paul,


On 07/10/2018 05:44 PM, Paul Wouters wrote:
> On Fri, 6 Jul 2018, Wouter Wijngaards wrote:
>
>> 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
===================================================================
--- services/listen_dnsport.c    (revision 4777)
+++ services/listen_dnsport.c    (working copy)
@@ -144,8 +144,17 @@
    
     for(i = 0; i < r; i++) {
         if(sd_is_socket(SD_LISTEN_FDS_START + i, family, socktype,
listen)) {
-            s = SD_LISTEN_FDS_START + i;
-            break;
+            if( (family == AF_INET || family == AF_INET6) ) {
+                if(sd_is_socket_sockaddr(
+                    SD_LISTEN_FDS_START + i, family,
+                    addr, addrlen)) {
+                    s = SD_LISTEN_FDS_START + i;
+                    break;
+                }
+            } else {
+                s = SD_LISTEN_FDS_START + i;
+                break;
+            }
         }
     }
     if (s == -1) {



Best regards, Wouter

>
> 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

_______________________________________________
nsd-users mailing list
[email protected]
https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
pEpkey.asc (application/pgp-keys, 11.4 KB)