Bug 995863 - dnsmaskq runs by default and breaks existing dhcpd and named services
dnsmaskq runs by default and breaks existing dhcpd and named services
Status: CLOSED DUPLICATE of bug 981973
Product: Fedora
Classification: Fedora
Component: dnsmasq (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Tomáš Hozza
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-11 11:26 EDT by josip@icase.edu
Modified: 2013-08-16 05:03 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-12 05:00:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description josip@icase.edu 2013-08-11 11:26:46 EDT
Description of problem: After a recent upgrade, dnsmaskq now runs by default and breaks existing dhcpd and named services


Version-Release number of selected component (if applicable):


How reproducible: Upgrade to recent Fedora 19 where dnsmasq runs by default


Steps to Reproduce:
1.
2.
3.

Actual results: dhcpd can't start because dnsmasq grabbed the port *:bootps


Expected results: normal function of existing setup


Additional info:

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?

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?
Comment 1 Tomáš Hozza 2013-08-12 05:00:38 EDT
(In reply to josip@icase.edu 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 ***
Comment 2 Laine Stump 2013-08-14 05:56:32 EDT
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?
Comment 3 Tomáš Hozza 2013-08-14 06:12:46 EDT
(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.
Comment 4 Laine Stump 2013-08-14 11:18:43 EDT
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.
Comment 5 josip 2013-08-15 07:44:18 EDT
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.
Comment 6 Tomáš Hozza 2013-08-15 08:08:34 EDT
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.
Comment 7 Laine Stump 2013-08-16 05:03:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.