# rpc.statd goes non-responsive, Ubuntu machine caused?

## mgnut57

I have a really odd situation. I just added an Ubuntu 10.04 Desktop to my network. The home directory for the main user of this Ubuntu machine is auto-mounted from my Gentoo server. 

It seems that immediately after the Ubuntu machine mounts the nfs export and then attempts to lock a file (I assume any of the files which contain user preferences/setup) the statd daemon stops responding. I haven't seen this happen with my Gentoo Desktop (which also auto-mounts home directories from the same Gentoo server), just the Ubuntu Desktop. 

Here is an example of the relevant message on the server:

Oct 28 17:15:55 localhost klogd: statd: server rpc.statd not responding, timed out

Does anyone have any ideas what could cause this odd behavior and, more importantly, how I fix it? 

Naturally, I ran revdep-rebuild as the first check for problems, but it reported no issues.

----------

## Jaglover

I had similar problem, a few Gentoo boxes mounted portage from FBSD server. Every now and then statd stopped responding. Finally I upgraded that FBSD box and problem went away.

----------

## mgnut57

 *Jaglover wrote:*   

> I had similar problem, a few Gentoo boxes mounted portage from FBSD server. Every now and then statd stopped responding. Finally I upgraded that FBSD box and problem went away.

 

I am beginning to suspect that it is due to mis-configured and conflicting dns/hosts. The client used a server called "fileserver", which resolved to a 192.168.x.x address, but on the server, "fileserver" referred to 127.0.0.1 in the /etc/hosts file (which has precedence).

----------

## mgnut57

 *mgnut57 wrote:*   

>  *Jaglover wrote:*   I had similar problem, a few Gentoo boxes mounted portage from FBSD server. Every now and then statd stopped responding. Finally I upgraded that FBSD box and problem went away. 
> 
> I am beginning to suspect that it is due to mis-configured and conflicting dns/hosts. The client used a server called "fileserver", which resolved to a 192.168.x.x address, but on the server, "fileserver" referred to 127.0.0.1 in the /etc/hosts file (which has precedence).

 

I fixed the DNS config and the problem remains, so my idea that it was related to the DNS/hosts setup is clearly false.

----------

## mgnut57

 *mgnut57 wrote:*   

> I have a really odd situation. I just added an Ubuntu 10.04 Desktop to my network. The home directory for the main user of this Ubuntu machine is auto-mounted from my Gentoo server. 
> 
> It seems that immediately after the Ubuntu machine mounts the nfs export and then attempts to lock a file (I assume any of the files which contain user preferences/setup) the statd daemon stops responding. I haven't seen this happen with my Gentoo Desktop (which also auto-mounts home directories from the same Gentoo server), just the Ubuntu Desktop. 
> 
> Here is an example of the relevant message on the server:
> ...

 

A long-overdue followup. 

I eventually found a file permission issue in my logfiles. Can't remember what the file was, but once I changed the permissions (or ownership), the problem went away. The reason that the Ubuntu box caused this while the Gentoo box did not was that the Ubuntu box was accessing the NFS files using the /net automount, which uses "showmount" against the nfs server. It was the showmount query (along with the permission issue) against the NFS server that caused rpc.statd to go unresponsive.

----------

