dnsmasq with --interface exits immediately if the interface does not exist yet

From a brief look at the code, it appears that the relevant section is in src/dnsmasq.c : 169-189. In this mode, if unable to access an interface because it doesn't exist, dnsmasq should poll the interface for a configurable timeout to see if it becomes available before quitting. As there may be multiple interfaces, implementing this as a push-to-back-of-queue delay until there is only one interface polling will ensure that the majority of intentionally specified interfaces come up as quickly as if all interfaces existed.

Emmet Hikory wrote:
>>From a brief look at the code, it appears that the relevant section is
> in src/dnsmasq.c : 169-189. In this mode, if unable to access an
> interface because it doesn't exist, dnsmasq should poll the interface
> for a configurable timeout to see if it becomes available before
> quitting. As there may be multiple interfaces, implementing this as a
> push-to-back-of-queue delay until there is only one interface polling
> will ensure that the majority of intentionally specified interfaces come
> up as quickly as if all interfaces existed.
>

[This covers 231060 too, they're basically the same problem.]

Such code would be possible, but shouldn't be necessary. Going back to
the original bug report, there are two problems, the first is the
race-condition in libvirt, which could be fixed (I assume) by a delay
between the synchronous creation of the virtual interface and the
starting of dnsmasq.

The second problem is, paraphrasing, "we have problems with network
interfaces which are created ad-hoc, come and go, and change IP address
over time." It's for precisely this use case that I carefully coded the
standard (ie not --bind-interfaces") network mode in dnsmasq, many years
ago. Without bind-interfaces, dnsmasq works exactly as you wish in these
circumstances. Many people have been using it with ad-hoc interfaces and
don't have any problems. This is a non-problem, _except_ that lib-virt
insists on running a private instance of dnsmasq, and therefore needs
the --bind-interfaces command.

Adding polling hackery to get something like the sane behaviour which is
available _by_default_ does seem like a bad idea, if there are other
alternatives.

Can we try and enumerate exactly what services libvirt wants from
dnsmasq on the virtual network? I think it should be possible to express
that as some configuration fragments that libvirt can drop into
/etc/dnsmasq.d and have a high confidence of not affecting any other
existing configuration on a "system" dnsmasq, or accidentally providing
services to non-virtual networks unless they are explicitly configured.
That way, libvirt can start up a dnsmasq instance a "system" dnsmasq is
not running, but defer to the system dnsmasq if it is.

The trick here would be for libvirt to start dnsmasq as

if <system dnsmasq is not installed or enabled>
     dnsmasq --interface=virt0 --bind-interfaces
else
     /etc/init.d/dnsmasq restart

That would inhibit the usual dnsmasq behaviour of offering service on
every interface unless configured otherwise. The --bind-interfaces means
that it will work even if the system is running eg BIND on port 53 of
other interfaces. By putting these on the command line, they won't be
seen when a system dnsmasq is installed.

The rest of the configuration could be dropped in /etc/dnsmasq.d and
suitably tagged so that it only applied to requests from virt0 (or
whatever it's called). That way they will be picked up by a system
dnsmasq and suitable service supplied to the virtual network by a system
dnsmasq.

Note the pid-file of the libvirt dnsmasq should be the same as a system
one, so that installing a system dnsmasq will stop the libv...

Something else that's required: we need to stop a libvirt-started
dnsmasq from picking up configuration left around by a removed system
dnsmasq, so the start-dnsmasq pseudo-code in libvirt becomes.

echo dhcp-range=interface:virt0,<ip range> >/etc/dnsmasq.d/libvirtf

if system dnsmasq is not installed or enabled>
      dnsmasq --interface=virt0\
        --bind-interfaces --conf-file=/etc/dnsmasq.d/libvirt
else
      /etc/init.d/dnsmasq restart

Simon.

    Actually, I filed this bug more as a result of the comments in the libvirt code, which indicate that at least one user of dnsmasq found it unable to accomplish an operation that seemed to make sense based on the documentation with a particular corner-case configuration.

    I consider it wishlist at best, and perhaps won'tfix. Addressing this is completely unnecessary to either allow libvirt and dnsmasq to interoperate or to permit users to use ad-hoc interfaces. It's also not necessarily the best way to address the case where someone wants to do both things at once (there being several other ways to do that well). It only exists to document either a decision that dnsmasq specifically doesn't support using --interface and --bind-interface in combination with an ad-hoc interface *or* that when used in this combination there is a potential for a race condition.

    Although this issue was initially raised in bug #231060, it's irrelevant to my current plan to address that bug, but since I won't be addressing this race condition in the resolution of that bug, I wanted to separate this out.

Emmet Hikory wrote:
> Actually, I filed this bug more as a result of the comments in the
> libvirt code, which indicate that at least one user of dnsmasq found it
> unable to accomplish an operation that seemed to make sense based on the
> documentation with a particular corner-case configuration.
>
> I consider it wishlist at best, and perhaps won'tfix. Addressing
> this is completely unnecessary to either allow libvirt and dnsmasq to
> interoperate or to permit users to use ad-hoc interfaces. It's also not
> necessarily the best way to address the case where someone wants to do
> both things at once (there being several other ways to do that well).
> It only exists to document either a decision that dnsmasq specifically
> doesn't support using --interface and --bind-interface in combination
> with an ad-hoc interface *or* that when used in this combination there
> is a potential for a race condition.
>
> Although this issue was initially raised in bug #231060, it's
> irrelevant to my current plan to address that bug, but since I won't be
> addressing this race condition in the resolution of that bug, I wanted
> to separate this out.
>

You're right that this is beyond the scope of the Ubuntu bugs. I've
opened negotiations with upstream libvirt development, that's clearly
the right path to take here. If it can be arranged that
--bind-interfaces is no longer needed, all of the problems fall out.

Cheers,

Simon.

Looking at the discussion this appears to be by design, so I propose we keep it as Wishlist at that point.

This bug was fixed in the package dnsmasq - 2.63-1ubuntu1

---------------
dnsmasq (2.63-1ubuntu1) quantal; urgency=low

  * Merge with Debian unstable; remaining changes:
    - debian/control: dnsmasq-base Breaks/Replaces dnsmasq (<< 2.62-3ubuntu1)
      due to the dbus config file move.
  * dnsmasq 2.63 noteworthy changes:
    - Allow setting a dbus name with --enable-dbus which overrides the default
      name. (LP: #1034946)
    - Add --bind-dynamic. A hybrid mode between default and --bind-interfaces
      which copes with dynamically created interfaces. (LP: #526386)
    - Fix regression in 2.61 which broke caching of CNAME chains.
    - Allow the target of a --cname flag to be another --cname.
    - Teach DHCPv6 about the RFC 4242 information-refresh-time option, and add
      parsing for the minutes, hours and days format for options.
    - Allow "w" (for week) as multiplier in lease times.
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 20 Aug 2012 14:24:30 -0400