Shulou(Shulou.com)06/03 Report--

Question:

A Solaris 10 host user is no longer in use. Check the NFS share status before the server shuts down to make sure there are no users connected to the host.

Check the connections of the client server with the command "showmount-e" and find that there is also a large list of connections. However, confirm with the user that the user said that the connection had been disconnected.

Solution:

=

Solaris host

The status of the user connection is recorded in the / etc/rmtab file. An abnormal NFS Client interrupt may have caused the umount nfs share point to fail, resulting in incorrect records remaining in / etc/rmtab.

You can restart the NFS service and empty the records with the following command.

Svcadm disable svc:/network/nfs/server:defaultcat / dev/null > / etc/rmtabsvcadm enable svcs:/network/nfs/server:defaultsvcs | grep nfs checks the startup status of the service

=

Similar problems can occur on the Linux platform.

Man rpc.mountd (8) says:The rmtab File... Note, however, that there is little to guarantee that the contents of / var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in / var/lib/nfs/rmtab.

It can be solved by the following command.

# service nfs stop# cat / dev/null > / var/lib/nfs/rmtab# service nfs start

=

Alternative inspection scheme:

The output of the "showmount-a" command may not be trusted because of an unexpected restart of nfs client.

To ensure that the user has no connection, you need to find other commands to check.

NFS protocol transfers files through RPC mechanism, and RPC still uses TCP/UDP to transfer files in the sending phase of file transfer.

Try to check all network connections with the "netstat-an | grep IP" command, check the output list, and make sure that the peer IP address does not have a user IP before shutting down the server.

Reference document 2:

Https://blog.csdn.net/wangpeng138375/article/details/8169071

Sun's RPC service

ONC RPC (Open Network Computing Remote Procedure Call) is an open source RPC framework developed by Sun Microsystem. It is the RPC de facto standard for UNIX systems. ONC RPC has been proved to be a high-performance technology. Most UNIX platforms, including Solaris,AIX,HP UX,Linux, support RPC services.

RPC is actually a programming mode of Cramp S, and its working process is shown in figure 2-3, which roughly consists of the following steps:

(0) the server starts, and it registers itself with the portmapper (port mapper) on the host. The client then starts, which calls clnt_create, and the function contacts the portmapper on the server host to find the server's temporary port. The clnt_create function also establishes an TCP connection to the server.

(1) the client invokes a local procedure called the client stub (Client stub), which is generated by the rpcgen tool. To the client, the client stub looks like the real server procedure it wants to call. The purpose of the stub is to package the parameters to be passed to the remote process, convert them to some standard format if possible, and then construct one or more network messages. The process of packaging customer-supplied parameters into a network message is called marshaling. Routines and stubs of client programs usually call functions in the RPC runtime library.

(2) these network messages are sent to the remote system by the client program stub. You usually need a system call (such as write or sendto) that gets stuck in the local kernel.

(3) these messages are delivered to a remote system, usually using the TCP or UDP protocol.

(4) A server server stub process waits for a customer's request on the remote system. It unmarshaling parameters from these network messages.

(5) the server program stub performs a local procedure call to activate the real server function, and the parameter passed to the function is that it is disbanded from the network message from the client.

(6) when the server process is completed, it returns its return value to the server program stub.

(7) the server stub converts the return values if necessary, and then aggregates them into one or more network messages for sending back to the customer.

(8) these messages are sent back to the customer through the network.

(9) the client stub reads these network messages (such as read or recvfrom) from the local kernel.

(10) after the possible conversion of the return value, the client program stub finally returns the client function.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.