Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
And for the sake of completeness, yes, NFS clients were able to mount the exported volume on this server once the nfs-kernel-server startup completed. And that makes a lot of sense to me now, because the entire issue was in rpcbind's attempt to verify that it could connect to 127.0.0.1, which does

Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
Hello, Thanks for the suggestions. The combination of checking /etc/network/interfaces and verifying that rpcbind was listening on 127.0.0.1 led me in the right direction, and boy do I feel silly... Somehow, my interfaces file was missing the loopback entry, so the loopback interface showed in t

Re: Long delays caused by rpcinfo

2013-09-24 Thread Tom H
On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx wrote: > David Parker wrote: >> >> I have confirmed that rpc.statd is running, which I believe is the port >> mapper in newer distributions. > > AFAIK rpc.statd is not a portmapper replacement. The two portmapper > equivalents that I am aware of are: >

Re: Long delays caused by rpcinfo

2013-09-24 Thread Mark Neyhart
David Parker wrote: > root@test-vm-1:~# cat /etc/hosts > 127.0.0.1localhostlocalhost > 192.168.25.200 testbed.utica.edu testbed > 192.168.25.201 test-vm-1.utica.edu test-vm-1 > 192.168.25.202 test-vm-2.utica.edu test-vm-2 > 192.168.25.203 test-vm-3.utica.edu test-vm-3

Re: Long delays caused by rpcinfo

2013-09-24 Thread Bob Proulx
I missed asking the obvious question. Does the NFS server work? Are you able to NFS mount it onto clients? Because this is the difference between some runtime functionality problem and a boot time functionality problem. David Parker wrote: > root@test-vm-1:~# cat /etc/hosts > 127.0.0.1local

Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
root@test-vm-1:~# cat /etc/hosts 127.0.0.1localhostlocalhost 192.168.25.200 testbed.utica.edu testbed 192.168.25.201 test-vm-1.utica.edu test-vm-1 192.168.25.202 test-vm-2.utica.edu test-vm-2 192.168.25.203 test-vm-3.utica.edu test-vm-3 192.168.25.204 test-vm-4.utica.

Re: Long delays caused by rpcinfo

2013-09-24 Thread Mark Neyhart
David Parker wrote: > Thanks for the reply. Unfortunately, it looks like rpcbind is not the > culprit. I verified that rpcbind installed and running: > > > Anything else I can look into? FWIW, an strace shows that rpcbind gets > stuck when trying to connect to a socket on the loopback interfac

Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
Thanks for the reply. Unfortunately, it looks like rpcbind is not the culprit. I verified that rpcbind installed and running: root@test-vm-1:~# ps -ef | grep bind root 1538 1 0 11:23 ?00:00:00 /sbin/rpcbind -w root 28002 2289 0 15:17 pts/000:00:00 grep bind I restart

Re: Long delays caused by rpcinfo

2013-09-24 Thread Bob Proulx
David Parker wrote: > I have confirmed that rpc.statd is running, which I believe is the port > mapper in newer distributions. AFAIK rpc.statd is not a portmapper replacement. The two portmapper equivalents that I am aware of are: portmap - RPC port mapper rpcbind - converts RPC program numb