Managing NFS and NIS, 2nd Edition - Mike Eisler [188]
mount: RPC: Program version mismatch
Even though Solaris supports Transport-Independent RPC (TI-RPC), in reality most RPC services use the TCP, UDP and loopback transport protocols. Servers may register themselves for any of the protocols, depending upon the varieties of connections they need to support. UDP packets are unreliable and unsequenced and are often used for broadcast or stateless services. The RPC server for the spray utility, which "catches" packets thrown at the remote host, uses the UDP protocol to accept as many requests as it can without requiring retransmission of any missed packets. In contrast to UDP, TCP packets are reliably delivered and are presented in the order in which they were transmitted, making them a requirement when requests must be processed by the server in the order in which they were transmitted by the client. The loopback transports are used for communication within the local host and can be connection-less or connection-oriented. For example, the automounter daemon uses RPC over a connection-oriented loopback transport to communicate with the local kernel.
RPC servers listen on the ports they have registered with the portmapper, and are used repeatedly for short-lived sessions. Connections to an RPC server may exist for the duration of the RPC call only, or may remain across calls. They do not usually fork new processes for each request, since the overhead of doing so would significantly impair the performance of RPC-intensive services such as NFS. Many RPC servers are multithreaded, such as NFS in Solaris, which allows the server to have multiple NFS requests being processed in parallel. A multithreaded NFS server can take advantage of multiple disks and disk controllers, it also allows "fast" NFS requests such as attribute or name lookups to not get trapped behind slower disk requests.
RPC registration
Making RPC calls is a reasonably complex affair because there are several places for the procedure to break down. The rpcinfo utility is an analog of ping that queries RPC servers and their registration with the portmapper. Like ping, rpcinfo provides a measure of basic connectivity, albeit at the session layer in the network protocol stack. Pinging a remote machine ensures that the underlying physical network and IP address handling are correct; using rpcinfo to perform a similar test verifies that the remote machine is capable of accepting and replying to an RPC request.
rpcinfo can be used to detect and debug a variety of failures:
"Dead" or hung servers caused by improper configuration or a failed daemon
RPC program version number mismatches between client and server
Bogus or renegade RPC servers, such as an NIS server that does not have valid maps for the domain it pretends to serve
Broadcast-related problems
In its simplest usage, rpcinfo -p takes a remote hostname (or uses the local hostname if none is specified) and queries the portmapper on that host for all registered RPC services:
% rpcinfo -p corvette
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32781 status
100024 1 tcp 32775 status
100011 1 udp 32787 rquotad
100002 2 udp 32789 rusersd
100002 3 udp 32789 rusersd
100002 2 tcp 32777 rusersd
100002 3 tcp 32777 rusersd
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100012 1 udp 32791 sprayd
100008 1 udp 32793 walld
100001 2 udp 32795 rstatd
100001 3 udp 32795 rstatd
100001 4 udp 32795 rstatd
100068 2 udp 32796 cmsd
100068 3 udp 32796 cmsd
100068 4 udp 32796 cmsd
100068 5 udp 32796 cmsd
100005 1 udp 32810 mountd
100005 2 udp 32810 mountd
100005 3 udp 32810