Cerin, in your earlier comment (#75) you posted the results of several
commands. The content of /etc/resolv.conf was incorrect. It was:
# Generated by NetworkManager
domain home
search home
nameserver 127.0.0.1
If this file had been generated by resolvconf, it would have begun with
the contents of /etc/resolvconf/resolv.conf.d/head and not with the
comment "# Generated by NetworkManager". Furthermore, resolvconf never
writes a "domain" line. Comparing with what you describe as the correct
contents, the domain and search lines are also incorrect, listing "home"
instead of "mynetwork".
In the later comment (#77) you say that /etc/resolv.conf contains
# Generated by NetworkManager
domain mynetwork
search mynetwork
nameserver 127.0.0.1
Although the domain and search lines are now "correct", the content is
still not what resolvconf generates, so there is still something amiss.
It appears as if NetworkManager is overwriting /etc/resolv.conf. (I say
"appears" because some other program or script could be copying from a
resolv.conf that was once generated by NM.) But NetworkManager also
calls resolvconf, as evidenced by the fact that
/run/resolvconf/interface/NetworkManager exists and has the same
creation date and time as /run/resolvconf/resolv.conf. Accordingly, in
the log file WifiSyslog.txt you posted originally we see the following.
May 16 09:42:03 coronis NetworkManager[22975]: <info> (eth2):
writing resolv.conf to /sbin/resolvconf
Looking in the network-manager source code I see what is most likely the
cause of the problem. The code in src/dns-manager/nm-dns-manager.c is
essentially the following.
success = dispatch_resolvconf (domain, searches, nameservers, iface,
error);
if (success == FALSE)
success = update_resolv_conf (domain, searches, nameservers,
iface, error);
With this code, if resolvconf returns nonzero for any reason then
NetworkManager writes its output directly to (the target of)
/etc/resolv.conf. This is wrong. I already wrote about this issue ten
months ago.
https://bugs.launchpad.net/ubuntu/+source/network-
manager/+bug/324233/comments/30
Although the most serious of the several problems I discussed there have
been fixed in Quantal, the problem remains that NetworkManager does not
correctly handle a nonzero exit status returned by resolvconf.
When resolvconf runs if may or may not return an error. For example, if
some update.d hook script returns a nonzero status then that status is
returned. But as NetworkManager is currently coded, if resolvconf
returns an error for any reason then NM writes its nameserver
information directly to /etc/resolv.conf.
That NM behavior dates from the time that resolvconf was an optional
package in universe which returned nonzero status to indicate that
/etc/resolv.conf wasn't a symbolic link, and the NetworkManager
maintainers wanted to avoid leaving the user without a resolv.conf at
all costs. The behavior was inappropriate then (because it failed to
distinguish between an absent symlink and runtime errors) and is more
inappropriate now.
The appropriate behavior for NetworkManager is: IF resolvconf is
installed as evidenced by the presence of the file /sbin/resolvconf THEN
send nameserver information to /sbin/resolvconf ELSE write the
nameserver information directly to (the target of) /etc/resolv.conf.
I will file a new bug report requesting that this finally be
implemented.
In the short term, though, Cerin, you should find out why resolvconf
returns a nonzero status (... assuming it does and that this is the
cause of your problem) and fix the underlying problem that causes it to
do so.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1000244
Title:
/etc/resolv.conf symlink does not exist after initial installation of
resolvconf package
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1000244/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
