The dnsmasq initscript fails to disable itself when the dnsmasq package is removed

[Josh Hill]

I upgraded from 12.04 to 14.04 and found that I had no DNS. After a little searching I noticed that dnsmasq, as started by Network Manager, was listening on 127.0.1.1, yet /etc/resolv.conf was being auto-populated with 127.0.0.1, so DNS lookups were failing.

Manually adding 127.0.1.1 to /etc/resolv.conf lets DNS work until the network state changes, then it gets overwritten again with 127.0.0.1.

I've worked around the issue by adding "nameserver 127.0.1.1" to /etc/resolvconf/resolv.conf.d/head and restarting network-manager. Something left over from 12.04 is apparently still causing 127.0.0.1 to be written instead of 127.0.1.1.

[Thomas Hood (jdthood)]

Can you find the "nameserver 127.0.0.1" line in one of the files in /etc/resolvconf/resolv.conf.d/ or /run/resolvconf/interface ?

[Josh Hill (ingenium)]

Yes, it's in /run/resolvconf/interface/lo.dnsmasq

I deleted the file and restarted network-manager and resolv.conf is generated correctly.

Weird that it completely ignored the other file in that directory, /run/resolvconf/interface/NetworkManager, which had the correct nameserver line but was never added into resolv.conf.

Thanks!

[Thomas Hood (jdthood)]

/run/resolvconf/interface/lo.dnsmasq arises from /etc/init.d/dnsmasq registering the standalone dnsmasq's listen address 127.0.0.1 with resolvconf. Normally the standalone dnsmasq listens at all addresses including 127.0.0.1. Did you have the standalone dnsmasq running?

It is normal that "nameserver 127.0.1.1" was in /run/resolvconf/interface/NetworkManager but not included in resolv.conf. Resolvconf normally includes at most one loopback address in resolv.conf.

[Josh Hill (ingenium)]

I don't remember having installed or setup the standalone dnsmasq daemon in the past. The dnsmasq package isn't installed (dnsmasq-base and dnsmasq-utils are though), yet it does appear that /etc/init.d/dnsmasq exists and does register 127.0.0.1 with resolvconf.

In /etc/default/dnsmasq it has ENABLED=1. Will changing this to ENABLED=0 disable the standalone dnsmasq and prevent it from registering 127.0.0.1 in the future? Or should I change it in /etc/init.d/dnsmasq instead? Or is there a better way to make sure it's disabled?

[Thomas Hood (jdthood)]

If the "dnsmasq" package is not installed then purging the dnsmasq package will remove /etc/init.d/dnsmasq and solve your problem.

Do not purge or remove the "dnsmasq-base" package. The dnsmasq-base package includes the dnsmasq binary which is used by NetworkManager.

Of course, the question remains: why was /etc/init.d/dnsmasq registering an address with resolvconf when the dnsmasq package was not installed?

Ahaaaa.

At the top of /etc/init.d/dnsmasq there is a "test - x /usr/sbin/dnsmasq || exit 0" which causes the initscript to exit if the dnsmasq binary is not present. When a daemon is packaged in the standard way, the binary is present if and only if the package is installed and a test like this suffices to disable the initscript if and only if the package is not installed.

But not in the case of the "dnsmasq" package. The binary is in dnsmasq-base. So the initscript does not disable itself when the dnsmasq package is removed.

This is a bug.

For reference, Debian policy §9.3.2 says the following.

«
These scripts should not fail obscurely when the configuration files remain but the package has been removed, as configuration files remain on the system after the package has been removed. Only when dpkg is executed with the --purge option will configuration files be removed. In particular, as the /etc/init.d/package script itself is usually a conffile, it will remain on the system if the package is removed but not purged. Therefore, you should include a test statement at the top of the script, like this:

     test -f program-executed-later-in-script || exit 0
»

I am quite surprised that this bug hasn't been noticed before.

Reading the initscript I see another bug: the script fails to look at the return value of the "start" function. I will file a separate report about that, since it is not the cause of your problem.

[Thomas Hood (jdthood)]

> the script fails to look at the return value

I was wrong; the script does look at the return value.

[Thomas Hood (jdthood)]

The Debian dnsmasq maintainer reports that he has uploaded a new version of the package for Debian. This will need to be pushed over to Ubuntu when it's available.

[Thomas Hood (jdthood)]

Fixed in Debian dnsmasq 2.71-1

[Thomas Hood (jdthood)]

Fixed in Utopic