[CentOS] URGENT: libdvdcss install hosed /var
MHR
mhullrich at gmail.com
Thu Dec 11 22:46:59 UTC 2008
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
More information about the CentOS
mailing list