resolvconf should not use dns info for interfaces that are down

[Benjamin Reed]

Binary package hint: resolvconf

Description: Ubuntu 8.04.1
Release: 8.04
resolvconf: 1.38ubuntu1

When resolvconf merges the dns information that it has collected to build a new resolv.conf, it should skip information from any interfaces that are down. I'm running into this problem because vpnc doesn't seem to be cleaning up its information when it dies abnormally, so its invalid information says in resolv.conf.

I think the problem is in list-records. It returns a list of interfaces for which there is dns information. I think it should return a list of interfaces for which there is dns information AND that interface is up. The attached patch does this.

[Cezary Baginski (cezary0)]

Benjamin's patch isn't in resolvconf trunk, I applied it locally and tested it with: vpnc + resolvconf + dnsmasq.

The patch now has an ugly workaround to work with dnsmasq also and works with more interfaces.

Although I think it would be better not to have vpnc die in the first place, so its resolvconf hooks fire, as they normally do.

The patch may solve problems when something dies and /etc/resolvconf/run/interfaces/* files are still left (It probably happened to me with dnsmasq and it's lo.dnsmasq file), so maybe a pid should be associated with the interface files?

If the pid doesn't exist anymore, we skip/delete the interface definition.

And note the strange newline echoing in the script - without it, it glues item together, e.g: eth0tun0 instead of eth0 tune0

[Philipp C. Heckel (binwiederhier)]

Ubuntu 8.10
resolvconf 1.42ubuntu2
network-manager 0.7~~svn20081018t105859-0ubuntu1
network-manager-gnome 0.7~~svn20081020t000444-0ubuntu1

I'm experiencing exactly the same as described in #51339, i.e. my /etc/resolv.conf looks like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1 ## wrong (from /etc/resolvconf/run/interface/eth1)
nameserver 134.x.x.x ## correct
search informatik.my-university.de

After choosing the network connection via the network manager (wired via eth0), /etc/resolv.conf is being rewritten by resolvconf. It also includes the /etc/resolvconf/run/interface/eth1 even if this interface is down.

Are there any intentions to adjust the behaviour of resolvconf as suggested by Benjamin Reed (the bug reporter)?

[Michael (michaeljt)]

Just seen this too. Also using vpnc - presumably it did not terminate correctly last time I shut down.

[Benjamin Reed (br33d)]

is there anyway to inspire action on this bug? it is still happening and it is super annoying!

[Thomas Hood (jdthood)]

One question is whether or not it is resolvconf's responsibility to check upness of interfaces. Resolvconf is really just a registry. Suppliers of nameserver information are responsible for updating the information they have supplied. So the bug in this case is certainly vpnc's.

Given that the bug exists and some maintainers are more responsive than others, it's conceivable that a workaround could be implemented in resolvconf.

But it would be a bit of a hack because resolvconf doesn't know for sure what interfaces correspond to what records. Suppliers of nameserver information run "resolvconf -a $X" for some value of X. By convention X has the value "${INTERFACE}.${SUPPLIER}" but not all suppliers follow this convention. So resolvconf can't be sure what interface should be checked. If a workaround were implemented it would have to be narrowly focussed on the vpnc case.

--
Thomas Hood
Debian resolvconf maintainers

[Benjamin Reed (br33d)]

someone has to do a check, because there are times that the cleanup will not happen. if vpnc gets a kill -9, it can't cleanup and it would be difficult to argue that that is a bug with vpnc.

there is a convention as you mention. if resolveconf enforced it, others would follow it. for that matter they already do seem to follow it.

in the end you can point the fingers how ever you want, but this problem is easy to address in a general way in resolvconf and is hard to address (and impossible to address in general) at the interface side.

this bug results in a really horrible user experience. it should be fixed.

[Thomas Hood (jdthood)]

Suppose resolvconf were to be changed so that it omitted information from resolv.conf that appeared to be associated with a "down" interface. What if a resolvconf update happens when some interface happens temporarily to be down? Information gets omitted even though it should not be. What if a package (e.g., NetworkManager) doesn't name records like interface names? Etc.

Keeping track of the networking subsystem is simply beyond the scope of resolvconf which is just a tiny bit of glue script.

vpnc should not die abnormally. If it does and this can't be fixed then someone should write a vpnc watchdog which takes appropriate actions when vpnc dies abnormally.