Description of problem: NetworkManager apparently adds an entry in /etc/hosts when it gets an IP address. The problem is that it doesn't remove it if the network connection is no longer present. This results in an /etc/hosts that looks like : x.x.x.x machinename # Added by NetworkManager 127.0.0.1 localhost.localdomain localhost ::1 machinename localhost6.localdomain6 localhost6 so that any lookups of machinename go to a non-accessible address. The severity of the problem is that virtually no gnome applications will function (in particular GDM, but also gnome-panel, etc.) without being able to access machinename (which should be 127.0.0.1), thus crippling the machine until /etc/hosts is fixed or the network connection resumes. Version-Release number of selected component (if applicable): NetworkManager-0.8.1-4.git20100817.fc13.i686 How reproducible: Always Steps to Reproduce: 1. Boot system 2. Plug in network wire and get IP address (/etc/hosts should be modified) 3. Unplug network wire (/etc/hosts stays the same) 4. Restart X and notice GDM no longer works Actual results: Lookups to machinename go to unreaching IP address instead of 127.0.0.1, GDM fails to function Expected results: /etc/hosts should be changed to put machinename back to 127.0.0.1 if no network is available Additional info: I ended up chattr +i /etc/hosts to keep it from being modified at all. Why should the local machinename ever point to anything other than 127.0.0.1?
Tested with new NetworkManager-0.8.1-6.git20100831.fc13.i686 and the same problem. If the laptop boots and you login, NetworkManager gets an IP address for the wireless adapter, changes /etc/hosts. If you then reboot, the change to /etc/hosts remains and GDM will not start since there is no route to 'machinename' which in /etc/hosts points to the Wifi address that is not up yet.
WTF!!! Why in the @#$% does NetworkManager add an entry to /etc/hosts anyway? This is absolutely stupid and ridiculous behaviour. I absolutely DO NOT want or need ANYTHING in the hosts file. We run local DNS, and I just wasted an HOUR of my time screwing around reconfiguring my HTTPD proxy ON ANOTHER MACHINE simply because NetworkManager changed my hosts file on THIS laptop a month ago and added an incorrect entry to /etc/hosts. So I thought it was a proxy problem ON ANOTHER MACHINE. . . Since /etc/hosts was incorrect the laptop was unreachable to itself. At this point I'm ready to just remove NetworkManager from this laptop before something else gets seriously screwed up ON ANOTHER MACHINE. I'd rather have to configure the wireless by hand than have this type of behaviour. There is absolutely no need for ANYTHING in /etc/hosts except localhost.
A quick Google search on this topic reveals this same behaviour in every distro. So the problem is definitely upstream. It looks like you can permanently set the hostname in the NetworkManager conf file. Then it won't change. But how does that help people who rely solely on DHCP for that? (Here come the gasps from all the sysadmins. . .but it's job security;) In our case, for example on my laptop, there are two DNS entries for it on the DHCP server. They are tied to the MAC addresses for eth0 and wlan0, and set the hostname according to the interface. So the hostname is either [HOSTNAME] or [HOSTNAME]-wlan0. We need it to be that way. But then NetworkManager causes problems with /etc/hosts. For now I suppose we must use the hack in comment #1. After reading all the bug reports it is evident that the described behaviour is utterly detested by just about everybody. So why is it there?
I can confirm this issue. It's really annoying. It's impossible to suspend & resume laptop, because after resume session cannot be unlocked. As a result I have to delete this line added by NM to /etc/hosts each time I want to shut down or suspend machine. This is a pure nonsens!
I don't see any troubles with the modification of /etc/hosts when I'm using GNOME programs. However, Sendmail, but maybe other programs, does a timeout so it takes a loooong time to just boot up. The trick with "chattr +i" helps me to get a laptop (connected to wireless networks very often) that doesn't ask me to take a coffee when it boots up. Unfortunately, the hostname is so set to localhost.localdomain.
I've heard that this bug was caused by a workaround added to NetworkManager to accomodate a bug in glibc when dealing with IPv6 and localhost name resolution. Laurent, I've further worked around the problem by setting the hostname in /etc/Networking/dispatcher.d. Its not pretty but adding an executable file in this directory containing : #!/bin/sh case "$2" in up) grep HOSTNAME /etc/sysconfig/network | cut -d= -f2 > /proc/sys/kernel/hostname ;; down) grep HOSTNAME /etc/sysconfig/network | cut -d= -f2 > /proc/sys/kernel/hostname ;; esac exit 0 works around NetworkManager setting the hostname to localhost.localdomain if it cannot write to /etc/hosts.
Upstream fixes: 82dd97c4b73ace6067fbe3fa92a3c7eb5a95e89b (master) 97de44c9a730fbb5a08d27e6899f7caffb015e66 (0.8.x)
Please test: rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2519251 f14: http://koji.fedoraproject.org/koji/taskinfo?taskID=2519259 f13: http://koji.fedoraproject.org/koji/taskinfo?taskID=2519238 f12: http://koji.fedoraproject.org/koji/taskinfo?taskID=2519242 The only change in these builds is the candidate fix for this bug.
This build seems to fix the problem. Initial tests are all positive. Thanks for your hard work fixing the issue.
NetworkManager-0.8.1-7.git20100831.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-7.git20100831.fc14
NetworkManager-0.8.1-7.git20100831.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-7.git20100831.fc13
NetworkManager-0.8.1-7.git20100831.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-7.git20100831.fc12
NetworkManager-0.8.1-7.git20100831.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-7.git20100831.fc14
NetworkManager-0.8.1-8.git20100831.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-8.git20100831.fc13
NetworkManager-0.8.1-8.git20100831.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-8.git20100831.fc14
NetworkManager-0.8.1-8.git20100831.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-8.git20100831.fc12
NetworkManager-0.8.1-8.git20100831.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.8.1-9.git20100831.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-9.git20100831.fc12
NetworkManager-0.8.1-8.git20100831.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Shouldn't the correct behaviour here be: 1. If network connected, set hostname to point to the actual IPs received from various connections. 127.0.0.1/::1 points to localhost only. For example: 127.0.0.1 localhost.locadomain localhost ::1 localhost6.localdomain6 localhost6 1.1.1.1 hostname.domain hostname 2.2.2.2 hostname.domain hostname 2. If network not connected, set hostname to point to 127.0.0.1/::1. 127.0.0.1 hostname.domain hostname localhost.locadomain localhost ::1 hostname.domain hostname localhost6.localdomain6 localhost6 No? PS. This is useful when one pings itself, for instance. Correct IP replies. Also, if someone (e.g. a developer) configured a virtual host with the name of the box on the IP in question, there will be problems getting to it using the name from the box itself, because 127.0.0.1/::1 will be used instead of the real address.
NetworkManager-0.8.1-9.git20100831.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
I just applied this patch to a system to fix this problem and it does not appear to be fixed. NetworkManager still does not remove the host entry when the network changes. Specifically: My user has a host named zenith. His own hostname is in his hosts file. 143.232.109.41 zenith.arc.nasa.gov zenith When he switches to wireless, network manager adds an entry: 198.123.51.105 zenith.arc.nasa.gov zenith # Added by NetworkManager When he then plugs back into the wired network, NetworkManager fails to remove this address. This makes things break (specifically flexlm), since his hostname now resolves to an incorrect ip. [root@zenith ~]# uname -r 2.6.34.6-47.fc13.x86_64 [root@zenith ~]# rpm -qa 'NetworkManager*' NetworkManager-gnome-0.8.1-9.git20100831.fc13.x86_64 NetworkManager-glib-0.8.1-9.git20100831.fc13.x86_64 NetworkManager-0.8.1-9.git20100831.fc13.x86_64