I lost my internet connection earlier today. My home network was still up - it's just the router couldn't get an IP from the cable modem.
During that period, my CentOS 5.1 install was extremely slow (2.6 GHz Athlon w/ 2GB ram) at starting non network applications - such as solitare and gnome terminal. It would pause for several seconds before finally starting them.
The machine does run bind as a caching nameserver - as I've found that to be more reliable than using my ISPs nameserver, so I'm guessing the slowdown was with bind not being able to resolve anything.
Is there anything I can do to prevent the slow application launching in the event of lost network in the future?
Startup wireshark... find out what those "non-network" apps are doing on the network.
What's your /etc/hosts file look like?
Michael A. Peters wrote:
I lost my internet connection earlier today. My home network was still up - it's just the router couldn't get an IP from the cable modem.
During that period, my CentOS 5.1 install was extremely slow (2.6 GHz Athlon w/ 2GB ram) at starting non network applications - such as solitare and gnome terminal. It would pause for several seconds before finally starting them.
The machine does run bind as a caching nameserver - as I've found that to be more reliable than using my ISPs nameserver, so I'm guessing the slowdown was with bind not being able to resolve anything.
Is there anything I can do to prevent the slow application launching in the event of lost network in the future? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, Apr 16, 2008 at 3:00 PM, Michael A. Peters mpeters@mac.com wrote:
I lost my internet connection earlier today.
During that period, my CentOS 5.1 install was extremely slow (2.6 GHz Athlon w/ 2GB ram) at starting non network applications - such as solitare and gnome terminal. It would pause for several seconds before finally starting them.
There's a couple of threads about this from May 2007 or thereabouts that you should be able to find in the list archives. (I know because I started those threads.) The short answer seems to be that Xorg gets annoyed if it can't resolve the local IP address to a hostname, and it attempts to do this any time any application connects to the X server. Other (non-X) apps will cause similar issues if they attempt DNS operations for any reason while the network is down.
You can fix *most* of this by making sure that there are entries in /etc/hosts for 127.0.0.1, etc., but I was never able to get the problem to entirely go away in all circumstances.
Bart Schaefer wrote:
You can fix *most* of this by making sure that there are entries in /etc/hosts for 127.0.0.1, etc., but I was never able to get the problem to entirely go away in all circumstances.
OK - my /etc/hosts file contained the following EXCEPT for the last line (fqdn) added this morning:
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost athens ::1 localhost6.localdomain6 localhost6 192.168.15.2 jerusalem.mpeters.local jerusalem 192.168.15.5 laserjet.mpeters.local laserjet 192.168.15.23 athens.mpeters.local
Hopefully it was lack of fqdn in /etc/hosts - though that would be puzzling, as I don't run any dns that defines that host name, so why it would cause slowdown when I can't reach the outside world because of lack of fqdn that it didn't have anyway is puzzling.
Another possibility - I have the gnome weather applet running on the panel, it could not update obviously as it could not get outside local lan, I don't know if that would have triggered gnome/x11 slowness or not.
Michael A. Peters wrote:
I lost my internet connection earlier today. My home network was still up - it's just the router couldn't get an IP from the cable modem.
During that period, my CentOS 5.1 install was extremely slow (2.6 GHz Athlon w/ 2GB ram) at starting non network applications - such as solitare and gnome terminal. It would pause for several seconds before finally starting them.
I've seen this issue showing up every once in a while for many years. It is _always_ due to DNS.
Just make sure that, even when offline, the system can still resolve things such as localhost, its own IP address, stuff like that. You can definitely find, always, what the problem is, by running a sniffer, a tracer/debugger, etc. It's just that it's time-consuming to troubleshoot due to the very nature of the problem - it takes a long time to elicit any kind of response from the system.
Make sure DNS is properly configured, test beforehand by pulling the network cable (so that network failure will not catch you unawares) and everything should then be fine.
I've been hit by this issue so many times that now I'm really obsessed with correct network and DNS settings. In the long run it's the good kind of obsession.
Tip: if the system is multihomed, and the DNS resolution for the external interface depends on a remote DNS server, do not configure the external interface as primary (do not assign the system hostname the same as the hostname for that interface). Instead, assign it the hostname corresponding to the internal interface, which is always under your control, and for whom the DNS never goes offline (since it's local). Then just juggle with Apache, Postfix, etc. settings if these services need to run primarily on the external interface. I can't explain this better in a short paragraph, but I'm sure there's plenty of people who've been there and arrived to the same conclusion: Anything remote is unreliable, so don't depend on it for local settings.
-
Bart Schaefer -
Florin Andrei -
Michael A. Peters -
Milton Calnek