[/etc/resolv.conf] Extra slow login / app launch

[José M. Vaz]

Binary package hint: network-manager

[Running NM 0.6.4 on feisty]

Since NM keeps /etc/resolv.conf between reboots, major slowdown can happen to the whole desktop if the networks changes between reboots.

Consider the following scenario, at different locations:

1) At work using wireless network. NM generated /etc/resolv.conf
2) Shutdown computer. Went home
3) At home, computer boots with previous /etc/resolv.conf

Unfortunately it can take up to 5 minutes for NM authenticate and establish connection to the home network (i must keep repeating password for some unknown and annoying reason).
The thing is, until i'm connected to the home network, the whole desktop is UNUSABLE since applications take a few minutes to start.

If I add the following script to /etc/init.d (to be run on boot and on shutdown), the logging process is MUCH faster, and applications start instantly:
------
#!/bin/sh
echo "nameserver 0.0.0.0" > /etc/resolv.conf
------

After a successful authentication NM generates a valid /etc/resolv.conf and no slowdown is experienced launching applications or logging in again.

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

The slow login/desktop bug appears to have been around for a while. The bug is reported in edgy & feisty and they are mostly unconfirmed and mostly of undecided importance. Although I'm very happy with feisty, I am finding this bug a bit bothersome so I thought I'd do some research through the bug archives.

I think this bug has been reported numerous times. The bug list that follows, I think are reports of effectively the same bug.

Bug #78263 - claims workaround (feisty)
Bug #78493 (edgy)
Bug #79466 (edgy)
Bug #80827 - claims workaround (edgy)
Bug #92997 - claims workaround (feisty)
Bug #94048 (feisty)
Bug #110616 (feisty?)
Bug #110775 (feisty)
Bug #110187 - reports slow desktop as a side effect of other network config issues. (feisty)
---------------
Bug #95264 - Maybe related (not clear) (feisty)
Bug #93447 - Maybe related (not clear) (edgy)
---------------
It seems most discussions are blaming this bug on one or more of:
Network-manager
avahi
hosts file
resolve file
static IP addresses
no network connection.

I can't vouch for the claimed workarounds - but I intend on investigating them further.

The person who solves this one will likely 'kill a number of bugs with one stone'.

I hope I'm not being too forward by presenting such a list but I am rather keen to see this bug solved. I hope this list helps to unify further discussion & prompts some further thought on the matter.

(note: I have posted it to all above bug reports so that all are in the loop)

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

Add Bug #79661 to above list.

[Henrik Nilsen Omma (henrik)]

I was able to reproduce something similar by commenting out 'auto lo' in /etc/network/interfaces on a gutsy system and rebooting. The general slow-down that results clearly isn't a network-manager bug but there probably is an n-m bug that messes up the localhost interface as well.

[Alexander Sack (asac)]

Henrik, network manager doesn't touch interfaces file. So this isn't a NM bug. If possible, please find a new home for this bug. I currently have no idea which application would do that. Maybe it ends up to be user-edited.

[Alexander Sack (asac)]

i think at least for the case where you don't mix network manager with /etc/network/interfaces managed devices, this bug should be fixed in network-manager 0.6.5-0ubuntu13. Please test and let us know.

Thanks,

 - Alexander

[Trond Husoe (tr-huso)]

I had the same problem after using network manager / network administration tool to add the work domain. When I removed it - with the network tools - it was still in /etc/resolv.conf. Removed all the lines that Network Manager had added and now programs on my is starting up nicely.
So NM or the network administration tool / configurator, isn't cleaning up after themselves in /etc/resolv.conf

best

Trond

[cicoandcico (cicoandcico)]

i don't think it is a network manager related problem. if network is managed trough the classic /etc/network/intefaces, the problem persists. i can confirm it in both my systems, a dell d830 notebook and a desktop.

when the configured network is not available, and you can't obviously connect, the system presents an embarassing slowness in logging in and opening applications like totem, terminal, nautilus. there is no processor or disk activity, it just waits a lot.
other apps like vlc, which are not part of the gnome desktop, don't seem to be affected.

i have no idea of what it could be. i remember, however, that about 1 year ago there was some people who reported the problem in the forum and claimed to be able to solve it by adding some line to resolv.conf, like:

localhost 127.0.0.1

[cicoandcico (cicoandcico)]

update: adding the above line does not have anything to do wiith the problem.

as said by Trond Husoe, the slowness is due to an unclean resolv.conf when no wired/wireless connection is established. it seems like when you're launching an application the computer tries to connect to the dns servers, but it can't, so the connection goes in timeout and the app is finally started.

the problem is still present when using wicd to manage the network: in this case, however, you just have to click the "Disconnect" button and resolv.conf is cleaned up. Apps launch lag is immediately fixed.
Unfortunately, NM does not have anything similar, just a "Enable wireless" button whose effect i ignore.

in the meanwhile, i temporary use a shell script that cleans resolv.conf every startup, but that's only a workaround. is that right?

another question: can anyone tell me why apps that don't have anything to do with the network, like gcalctool, are suffering of the problem?

[spanella (spanella)]

do you use the script in the bug description? and just put that file in /etc/init.d?

[cicoandcico (cicoandcico)]

yes, it is a workaround but is is not the right way to solve the problem imho. you should clean resolv.conf *every* time the network is disconnected, clicking wicd's "disconnect" button, for instance.
but this is still a workaround: the right way, i think, is making application stop looking for dns on startup, as i suppose they're doing. but i'm quite ignorant about the question.

I think, however, that the problem is a serious limitation for a mobile platform. if ubuntu is supposed to be able to manage a mobile scenario, it should be able to handle disconnections, not just connections, and it should not turn into a slow system every time the connection is unavailable.

but, i repeat, i'm lacking necessary knowledge to speak about that. there probably are non-trivial causes.

[Max-Ulrich Farber (maxulrichfarber)]

I have replaced the Network Manager by WICD, and there is no such problem any more. It seems to me that WICD does the same work without changing anything in /etc/resolv.conf.

There seems to be a problem if the IP of the rooter is written in resolv.conf as a DNS_server. My rooter takes a very long time to send a "not found" message. If there are only the two DNS-servers of my provider, I get the message in about 60 ms.

[Alexander Sack (asac)]

bug 256480 takes care that resolvconf works. this on top of the general improved capability of NM 0.7 should fix this. Marking this bug as fixed for next upload.

[Alexander Sack (asac)]

resolvconf is now properly supported.