Bug 995863

(In reply to josip from comment #0)
> Just saying "systemctl disable dnsmasq.service" doesn't suffice, because
> dnsmasq comes back and breaks dhcpd service.  It's unclear why this happens.
> Also, saying "systemctl stop dnsmasq.service" doesn't stop the service; the
> offending dnsmasq process must be killed separately.  Why doesn't "systemctl
> stop dnsmasq.service" work properly?

If you have a virt-manager then dnsmasq is run by it for every network created
in virt-manager that uses DHCP and DNS.

> My machine provides a number of named, dhcpd, and other services to multiple
> networks, with complex configuration.  I'm not ready to switch to dnsmasq,
> and need a RELIABLE way to turn it off and keep it off, short of
> uninstalling dnsmasq (since NetworkManager and libvirt-daemon depend on
> dnsmasq).  My basic objective is to keep the existing dhcpd and named and
> other services working without interference from dnsmasq.  How?

If you don't use virt-manager I would recommend removing it or stopping all
networks created in virt-manager.

I'll have a look at possible fix for this issue as it seems to affect more
users than I thought.

*** This bug has been marked as a duplicate of bug 981973 ***

Are we certain that the dnsmasq that's running originates from libvirt's virtual networks? What is the dnsmasq commandline that shows up in the output of ps -AlF?

(In reply to Laine Stump from comment #2)
> Are we certain that the dnsmasq that's running originates from libvirt's
> virtual networks? What is the dnsmasq commandline that shows up in the
> output of ps -AlF?

I tested it with dnsmasq run by libvirt and ISC DHCP and they were really
conflicting. In this case I personally don't see any way how dnsmasq run by
libvirt could be conflicting with named (ISC BIND). Hopefully the reporter will
respond.

Right. I'm not questioning the problem wrt the dnsmasq run by libvirt vs dhcpd, but am wondering if maybe this is yet another problem since he didn't mention having libvirt installed/running either before or after the update.

Sorry about responding late.  On this system, libvirtd.service was running, apparently enabled by default during a previous upgrade (it's not needed, so I disabled it now).  Package virt-manager is installed but I didn't start it, unless system upgrades did that by default.  The machine runs as multi-user.target, not graphical.target.

Since dnsmasq broke my dhcpd, I never got to test whether named was also affected.  Perhaps it wasn't.

The machine now defends itself against rogue configuration changes by doing this on reboot:

# Confirm that dnsmasq.service is disabled:
systemctl --quiet is-enabled dnsmasq.service && systemctl disable dnsmasq.service

So far, this crude method seems to work, but there has to be a better way.

Please try the following dnsmasq update:
https://admin.fedoraproject.org/updates/dnsmasq-2.66-10.fc19

dnsmasq should now run without conflict with ISC DHCP.

To clear up a couple possible misunderstandings

1) virt-manager is just a frontend to libvirt, and does not itself start up any libvirt networks or dnsmasq instances - this is all done by the libvirtd service regardless of whether or not virt-manager is running or even installed.

2) if libvirtd creates a virtual network that requires an instance of dnsmasq, it will run it directly, not via the dnsmasq service (which is only able to run a single instance of dnsmasq, while libvirt requires a separate dnsmasq for each virtual network. So disabling the dnsmasq service will not stop any libvirt instances of dnsmasq.

If disabling the dnsmasq service is eliminating your problem (as you described in Comment 5), then there is a problem somewhere beyond the dnsmasq instances created by libvirt (note that there have been instances in the past where upgrading the dnsmasq package caused it to be enabled by default - this even made problems for libvirt because the default dnsmasq configuration conflicted with libvirt's use of dnsmasq). (I hope that's not the case, because it will be easier if Tomas's recent update to dnsmasq has fixed it for you :-)

If it *is* the case that the libvirt package wsa not previously installed, and was somehow installed due to a new dependency that came in with an update, it would be interesting to know what other package is newly dependent on the libvirt package - possibly this is an unnecessary dependency that can be removed.