Comment 5 for bug 1639452

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Enough late posts for a lack of activity on this, this time I think we can close it :-)

What used to be:
ExecStartPre=/usr/sbin/dnsmasq --test

Nowadays is:
ExecStartPre=/etc/init.d/dnsmasq checkconfig
that maps it to
${DAEMON} --test ${CONFIG_DIR:+ -7 ${CONFIG_DIR}} ${DNSMASQ_OPTS:+ ${DNSMASQ_OPTS}} >/dev/null 2>&1

Which includes not only config-dir but also all other configs that might affect it.

It is not yet started as After=systemd-resolved.service but tolerates both modes nowadays.
1. with systemd-resolved stopped

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-11-17 15:49:59 UTC; 5s ago
    Process: 29898 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 29906 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 29915 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
   Main PID: 29914 (dnsmasq)
      Tasks: 1 (limit: 38266)
     Memory: 2.0M
     CGroup: /system.slice/dnsmasq.service
             └─29914 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>

Nov 17 15:49:59 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Nov 17 15:49:59 j dnsmasq[29914]: started, version 2.85 cachesize 150
Nov 17 15:49:59 j dnsmasq[29914]: DNS service limited to local subnets
Nov 17 15:49:59 j dnsmasq[29914]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Nov 17 15:49:59 j dnsmasq[29914]: reading /etc/resolv.conf
Nov 17 15:49:59 j dnsmasq[29914]: using nameserver 127.0.0.53#53
Nov 17 15:49:59 j dnsmasq[29914]: read /etc/hosts - 7 addresses
Nov 17 15:49:59 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

2. with systemd-resolved stopped and /etc/resolv.conf removed

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-11-17 15:50:41 UTC; 3s ago
    Process: 29937 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 29945 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 29954 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
   Main PID: 29953 (dnsmasq)
      Tasks: 1 (limit: 38266)
     Memory: 1.8M
     CGroup: /system.slice/dnsmasq.service
             └─29953 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c>

Nov 17 15:50:41 j systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Nov 17 15:50:41 j dnsmasq[29953]: started, version 2.85 cachesize 150
Nov 17 15:50:41 j dnsmasq[29953]: DNS service limited to local subnets
Nov 17 15:50:41 j dnsmasq[29953]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Nov 17 15:50:41 j dnsmasq[29953]: read /etc/hosts - 7 addresses
Nov 17 15:50:41 j systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

In none of these modes it gets stuck and I'm unsure if adding the After nowadays would really be right. Even if so as I explained in the past that should go through a report to the Debian bug tracker as the issue is not Ubuntu specific in this case and we'd like to fix both.

---

Backports of this change are unlikely to qualify for the SRU process [1] as the rework of the init scripts can have plenty of side effects that might break existing users.

So the check it runs in ExecStartPre might be useless, but only if it would really break people (and I've not seen reports other than this one, so it might not be that common of a problem at all) it might justify the risk of changing that. It is valid for a backport, but IMHO low prio and probably not done unless somebody speaks up outlining why this is more severe than it seems.

Bionic is still affected, I'm marking this as such.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates