[Dnsmasq-discuss] patch to support systemd socket activation

[Max Nikulin]

Hi,

In the year 2011 there was a discussion of systemd socket activation for 
systemd and the patches were resend in 2012.
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2011q4/005324.html
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q3/006193.html
An example of objections are quoted below. I believe, everybody almost 
forgot the context and it is an excuse for top posting.

I wonder if rejection of the feature may be reconsidered. I will try to 
address the raised questions.

Motivation. Cases when dnsmasq is used for experiments, not as the 
primary DNS server. As a result days may pass since boot till it will be 
started. Postponing starting of the server means a bit quicker boot and 
a bit less resource usage while it is not necessary.

D-Bus activation is already implemented. D-Bus is control interface 
while the proposed feature allows to start process when a DNS or a DHCP 
packet is arrived. They are independent features.

External dependency. My impression is that a self-contained files are 
added to the patch. Only environment variables and inherited file 
descriptors are involved. The same executable should work with any init 
implementation.

I agree that some maintenance load is added to sync added files with 
latest versions provided by the systemd project.

Can socket activation work with DHCP? I do not see any obstacles. As a 
proof of concept I have tried a kind of socket activation for poors.

Since DNS and DHCP assumes retries, I think, I can afford missed 
response to first packet. Of course, it means some delay and it still be 
great to have the feature available. Fortunately systemd allows to have 
conflict between socket and service unit, so systemd may close sockets, 
it is listening, before starting the server. Unit files may need further 
tuning to get better behavior in corner cases or in response to errors.

File /etc/systemd/system/dnsmasq-ondemand-br1.socket

[Unit]
Description=dnsmasq socket for activation for br1

[Socket]
# "%%" to prevent "%" specifiers expansion.
ListenDatagram=0.0.0.0:67%%br1
ListenDatagram=10.0.15.1:53%%br1
ListenStream=10.0.15.1:53%%br1
BindToDevice=br1


File /etc/systemd/system/dnsmasq-ondemand-br1.service

[Unit]
Description=dnsmasq activated by socket
# Stop on interface down. It is not enough to prevent
#     error binding DHCP socket to device br1
BindsTo=sys-subsystem-net-devices-br1.device
# Drop connection to a socket opened by systemd
# and start dnsmasq as usual.
Conflicts=dnsmasq-ondemand-br1.socket
After=dnsmasq-ondemand-br1.socket

[Service]
ExecStart=/usr/sbin/dnsmasq --conf-file=/dev/null \
     --interface=br1 --bind-dynamic --except-interface=lo \
     --keep-in-foreground --pid-file= \
     --dhcp-range=10.0.15.2,10.0.15.128 \
     --dhcp-leasefile=/run/dnsmasq-ondemand-br1.leases
ExecReload=/bin/kill -HUP $MAINPID


Adjust the interface name and IP addresses then

     systemctl daemon-reload
     sustemctl start dnsmasq-ondemand-br1.socket
     dig thekelleys.org.uk @10.0.15.1


Alternatively it is possible to create transient systemd units. Example 
of a script that does not require unit files:

#!/bin/sh -e

iface='br1'
unit="run-dnsmasq-ondemand-$iface"

! systemctl is-active "$unit.service" >/dev/null ||
      systemctl stop "$unit.service"
! systemctl is-active "$unit.socket" >/dev/null ||
      systemctl stop "$unit.socket"
! systemctl is-failed "$unit.service" >/dev/null ||
      systemctl reset-failed "$unit.service"
! systemctl is-failed "$unit.socket" >/dev/null ||
      systemctl reset-failed "$unit.socket"

# "Conflicts" and "After" are added to close sockets
# opened by systemd before starting the service unit.
# First request is ignored.
systemd-run --unit "$unit" \
      --description="dnsmasq on demand at $iface" \
      --socket-property="ListenDatagram=0.0.0.0:67%$iface" \
      --socket-property="ListenDatagram=10.0.15.1:53%$iface" \
      --socket-property="ListenStream=10.0.15.1:53%$iface" \
      --socket-property="BindToDevice=$iface" \
      --property="Conflicts=$unit.socket" \
      --property="After=$unit.socket" \
      --property="BindsTo=sys-subsystem-net-devices-$iface.device" \
      --property='ExecReload=/bin/kill -HUP $MAINPID' \
      -- \
      /usr/sbin/dnsmasq --conf-file='/dev/null' \
          --keep-in-foreground --pid-file='' \
          --interface="$iface" --bind-dynamic --except-interface=lo \
          --dhcp-range='10.0.15.2,10.0.15.128' \
          --dhcp-leasefile="/run/dnsmasq-ondemand-$iface.leases"


Ideally it should be possible to have template units 
dnsmasq-ondemand at .socket and .service allowing

     systemctl start dnsmasq-ondemand at br1.socket

Unfortunately systemd allows to have single parameter only. If I 
understand it correctly, dnsmasq currently can not guess IP address 
range for DHCP when just interface name is given. Another issue is 
systemd. It does not allow "%i" instance name (parameter) specifier in 
the BindToDevice property. It throws an error if IP address is not 
explicitly specified for ListenStream. So parametrized template needs a 
per-instance drop-in file with some properties.

I hope, support of socket activation may be added to dnsmasq. Perhaps 
somebody will find useful the recipe for fake socket activation.

Finally an example of a message from the decade old discussion:

On 18/11/2011 02:33, Michael Stapelberg wrote:
> Hi Sergei,
> 
> Excerpts from Sergei Zhirikov's message of 2011-11-17 19:02:22 +0000:
>> some good ideas in its design, but the one of socket activation, IMO, is
>> blown up to the point of being ridiculous. Everyone seems to be adding socket
> I think it?s very elegant and useful.
> 
>> activation support to their applications just because everyone else is doing
>> that. I think dnsmasq is a good example of an application that would *not*
>> benefit from such an addition. TFTP support in dnsmasq is intentionally
> I agree. I think the DBus-using systemd service file is just fine.
> 
>> In other words, I don't think dnsmasq needs socket activation.
> Yap. I would suggest that this patch does not get merged, unless the author
> clarifies why he thinks it?s a good idea :).
> 
> Best regards,
> Michael