[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