It seems that Linux systems have extremely long timouts in some programs.

This afternoon I had to move my primary server (firewall, DHCP, DNS, VPN, NFS) to the other side of the room. Unfortunately this involved cycling the power.

When I booted up the system again, it was not working. That is, firewall, DHCP, VPN and DNS, MySQL were working, but NFS, Apache, SHH and TTY were not. Not even after 15 minutes. (Do you know how unusable your network becomes if every client has a number of connected NFS drives?)

That is a bad sign, so I started to connect a terminal and keyboard (only to discover that TTY wasn't there). Booted into Knoppix, booted into single user mode, etc, went all the works. Nothing, nothing, nothing at all.

Nothing to see in the logs. I went thru each and every log. Disabled and removed everything which I installed the last three months. NIL.

So I gave up. Happy that at least the firewall and VPN were still working I postponed the problem to the next day after 5 hours of work. While I was writing a message to this forum to ask for assistance in debugging, suddenly the network popped up again. After 20 to 25 minutes. As it seems, PostgreSQL might have been the culprit, but again, no traces in the logs.

What's this? Apparently I should have waited more than 15 minutes before starting to worry? Just because ONE process could not start? On a live server?

What is the purpose of these long timeouts? Wait until the next stable version comes out before continuing? Or the answer to the question what's the meaning of life and evertyhing?

As I am writing this on a Debian Etch system, I tried to answer an email in Kwrite. When I hit the "reply" button, the hour glass appeared. (Possible this is an aftermath of the network problems I had before) But it took THREE minutes before the reply window popped up.

I would say that in 2007 with ping times of 200 ms from one host to the other spanning half the planet Earth, timouts could be a *little* shorter so that you know at least whether the system failed, or is just waiting for something. I can live with crashing applications, especially if they log what's wrong. But applications rendering the system unusable and inaccessible until they are so graceful to timeout make me less happy.

jlinkels

One thing to look at is disabling IP V6 support. Also look at the output of the top command. One process may be hogging resources.

I am totally ignorant about the status of IPv6, whether it is being used or what ifluence it has on your system. I should take a look into that. Thanks.

For 'top' etc, I know about that. But during the incident I was not able to access the machine.

jlinkels

Here is another posting on this site about disabling IPv6.
http://www.linuxquestions.org/questi...light=IPv6+kde

Also look at your /etc/resolv.conf and /etc/nsswitch.conf files.

For 15 minute wait times, it sounds more like a resource problem then a name resolving timeout problem. I've noticed a problem at home with the cups daemon eating up resources. Top and other diagnostics programs can help determine if you have such a runaway process.

Thanks for the pointer about IPv6

When I was investigating the problem (once I had console access) I found out that it was exportfs which held up everything. When running this program with '-v' I could see that the timeout begun at the first line it had to resolve an address. Processor load was zero

I posted this thread about it:
http://www.linuxquestions.org/questi...d.php?t=576638

As you correctly suggested it had something to do with one invalid entry in resolv.conf. One name server for the LAN name resolution had gone down, the other one was still there.

My point remains that for a production environment a 20 minute timeout *is* a little long, especially if this process runs before the TTY's are initiated. It had nothing to do with the number of names that had to be resolved, after it was discovered that none of the names would resolve, the process continued at once.

jlinkels