Comment 22 for bug 324233

I don't think is a correct fix; NetworkManager should *not* overwrite the file pointed to by the /etc/resolv.conf symlink.

I've got two systems here running Kubuntu Karmic Koala, with NetworkManager (and kdenetworkmanager), dhclient, dnsmasq, resolvconf and openvpn installed. If boot in single user mode, ensure that /etc/resolv.conf is the proper symlink (by running 'dpkg-reconfigure resolvconf' and accepting all the defaults), then boot normally, everything is fine... NetworkManager connects to my wireless network after I log in, but /etc/resolv.conf still points only to 127.0.0.1 (as it should, since I'm running dnsmasq).

However, on a reboot, /etc/resolv.conf becomes a regular file again. So I downloaded the network-manager source, and added a bunch of logging statements in nm-named-manager.c to see what is going on. I can see that everything works properly as the network connection is brought up.

At shutdown, I can see that dispatch_resolvconf() gets called as the connection is brought down, and it calls resolvconf to update the information as it should. However, I can't see what happens after that, because rsyslog gets shutdown before NetworkManager finishes shutting down the link... but I suspect what is happening is that dispatch_resolvconf() gets called *twice* at shutdown (it does also at connection startup) and the second time nm_spawn_process() fails because the system won't allow new processes to be started, or something similar. I didn't take the time to modify NetworkManager to log its messages to a separate file (not via syslog, so it could continue logging right until the filesystem is unmounted), but as best I can tell this is the point where the /etc/resolv.conf symlink gets destroyed.

Really, I'd prefer to have NetworkManager *never* call update_resolv_conf() if the file pointed to by RESOLVCONF_PATH is executable; if it fails, then it fails, but directly writing /etc/resolv.conf is not a safe backup plan, because it will avoid any other name resolution configuration the user has setup. Can we consider just making NetworkManager use resolvconf, *or* the TARGET_SUSE method, *or* directly writing /etc/resolv.conf, but never falling back from one to the other?