On Apr 15, 2009, at 3:17 PM, Hans-Peter Jansen wrote:
Am Mittwoch, 15. April 2009 schrieb Chuck Lever:
On Apr 15, 2009, at 1:23 PM, Hans-Peter Jansen wrote:
Am Mittwoch, 15. April 2009 schrieb Chuck Lever:
When using rpcbind instead of portmapper, what does the output of
"rpcinfo" look like on the server?
It's dumped in the mail starting this thread.
I don't see why the client's rpcbind attempt for the server's mountd
service should have failed.
For completeness, here's the current rpcinfo view with portmap:
# rpcinfo -p 172.16.23.110
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 54838 mountd
100005 1 tcp 32772 mountd
100005 2 udp 54838 mountd
100005 2 tcp 32772 mountd
100005 3 udp 54838 mountd
100005 3 tcp 32772 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 35501 nlockmgr
100021 3 udp 35501 nlockmgr
100021 4 udp 35501 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 54766 nlockmgr
100021 3 tcp 54766 nlockmgr
100021 4 tcp 54766 nlockmgr
100024 1 udp 44650 status
100024 1 tcp 39765 status
Would it be possible for you to capture a packet trace of the
client's
attempt to mount it's root file system? (You will likely need to do
this for a bugzilla report, anyway).
Ähem, Chuck, may I ask you to look into the initial mail again. The
failing
case is attached there. Here I've attached the good one. Since I
couldn't
locate any mount attempt in the dump, I've left a few more nfs
transactions.
The client makes a PMAP_GETPORT request via TCP. The server's rpcbind
drops the connection without replying after receiving the request. I
didn't see anything immediately wrong with the request, although
wireshark didn't like it either. I had to decode it by hand.
Restarting rpcbind usually means you lose all your rpc service
registrations until you restart those services, but it would be worth
trying this: stop the server's rpcbind service, then run rpcbind in a
terminal session with "-d" to see what it thinks the problem is when
it drops the connection.
Please attach a copy of your /etc/netconfig to reply.
Also let us know what's running on your clients (distribution, kernel
version, etc).
Hmm, sure. The client setup is a legacy SuSE 9.3 diskless environment
(unfortunately Novell didn't manage to create a distribution with
similar
stability since then..., being a rpm junke, I will soon check Cent-OS
(again)).
Client (relevant) versions:
Kernel: 2.6.11.4
Udev (nfsmount): 053
Let me know, what more I can provide, please.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
