On Thu, Dec 11, 2008 at 1:32 PM, Toby Bluhm <tkb at alltechmedusa.com> wrote: > MHR wrote: > > Gnome at one time (RH9 days I think) was painfully slow to start after a > hostname change, until it udpated itself in all places - or whatever it > was doing. Is your hostname & /etc/hosts still intact? If it's been up > for a while, I would expect it to resolve itself already. That's how it > used to was anyway. > All that looks ok so far. > Nothing in the log files? top show anything of interest? > Just this, in /var/log/messages: Dec 11 14:38:07 swordfish kernel: statd: server localhost not responding, timed out Dec 11 14:38:07 swordfish kernel: lockd: cannot monitor 10.24.15.48 Dec 11 14:38:07 swordfish kernel: lockd: failed to monitor 10.24.15.48 Dec 11 14:38:37 swordfish kernel: statd: server localhost not responding, timed out Dec 11 14:38:37 swordfish kernel: lockd: cannot monitor 10.24.15.48 Dec 11 14:38:37 swordfish kernel: lockd: failed to monitor 10.24.15.48 Dec 11 14:42:06 swordfish kernel: statd: server localhost not responding, timed out Dec 11 14:42:06 swordfish kernel: lockd: cannot monitor 10.24.15.48 Dec 11 14:42:06 swordfish kernel: lockd: failed to monitor 10.24.15.48 This happens a lot. 10.24.15.48 is our internal /home nfs machine, so that might be involved (slow access to /home can cause a lot of problems). I don't know why localhost would be a problem. Here's my /etc/hosts and ifconfig output: [mrichter at swordfish ~]$ sudo cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost localhost.localdomain ::1 localhost.localdomain localhost 192.168.9.225 swordfish swordfish.sjhtca.com 192.168.9.92 t-mrichter-08 t-mrichter-08.sjhtca.com [mrichter at swordfish ~]$ ifc eth0 Link encap:Ethernet HWaddr 00:1C:C0:1F:5E:38 inet addr:192.168.9.225 Bcast:192.168.9.255 Mask:255.255.255.0 inet6 addr: fe80::21c:c0ff:fe1f:5e38/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31680 errors:0 dropped:0 overruns:0 frame:0 TX packets:28897 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:25685445 (24.4 MiB) TX bytes:15109432 (14.4 MiB) Memory:92200000-92220000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:363 errors:0 dropped:0 overruns:0 frame:0 TX packets:363 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:33380 (32.5 KiB) TX bytes:33380 (32.5 KiB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet addr:192.168.240.1 Bcast:192.168.240.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:82 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) During startup now, the only process that fails is NFS statd, which probably fits right into the above, but I know zip about this area. Any suggestions? This wasn't happening before, and it doesn't happen on my backup machine at all (surprise!). Thanks. mhr