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

This article focuses on "skills for using rsh remote shell commands in Linux". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "the skills of using rsh remote shell commands in Linux".

There are two usage modes for rsh:

Rsh $host: log in remotely to start an interactive process.

Rsh $host $command: executes the command remotely and displays the output.

Rsh hosthostcommand

The purpose of rsh $host $command is:

1. Execute the command $command on the remote machine

two。 Redirect standard input and standard output of current and remote processes over a network connection (socket)

3. The remote rsh process ends after the remote process ends

4. The local rsh process reads the standard output of the remote process until the end (EOF)

A deep understanding of this implementation process helps to understand a variety of "strange" phenomena and uses.

The code is as follows:

+ Suspended (tty input)

$rsh localhost infinite-loop &

[1] + Suspended (tty input) rsh pv007 infinite-loop

$rsh-n localhost infinite-loop &

# execute normally

When the rsh command is executed in the background, an error message related to standard input is prompted. This is because rsh redirects the standard input of the current window to the remote process by default.

While the local rsh process runs as a daemon, standard input is "blocked".

With the-n option, there is no need to redirect standard input (stdin).

Execution of remote processes

Execute a command

The code is as follows:

Rsh somehost infinite-loop

View the relevant processes on the remote machine:

The code is as follows:

$pstree-a-p 3353

In.rshd,3353

└─ csh,3363-c infinite-loop

└─ infinite-loop,3632 / u/szhang/bin/infinite-loop

As you can see, the rshd process on the remote machine is responsible for starting the remote process. And you can see that it was started through csh-c (here the user's default Shell is C Shell).

Standard IO for remote processes

Check the file descriptor of the remote process:

The code is as follows:

$ls-l / proc/3363/fd / proc/3632/fd

/ proc/3363/fd:

Total 0

Lrwx-. 1 Jul 30 23:47 16-> socket: [1184748899]

Lrwx-. 1 Jul 30 23:47 17-> socket: [1184748899]

L / w / w 1 Jul 30 23:47 18-> pipe: [1184749092]

Lrwx-. 1 Jul 30 23:47 19-> socket: [1184748899]

The code is as follows:

/ proc/3632/fd:

Total 0

Lrwx-. 1 Jul 30 23:47 0-> socket: [1184748899]

Lrwx-. 1 Jul 30 23:47 1-> socket: [1184748899]

L / w / w 1 Jul 30 23:47 2-> pipe: [1184749092]

You can see that the standard input and output of the remote mileage is redirected to the socket:

1.stdin and stdout share a socket connection

2.stderr is redirected through a pipe (redirected to stdout)

The return value of 3.rsh

The return value of the rsh program itself indicates the health of the rsh itself, not the return value of the remote process.

Get the return value of the remote process

The code is as follows:

# the remote end is C Shell

$rsh $host "$command; echo $status"

The code is as follows:

# the remote end is Bash Shell

$rsh $host "$command; echo $?"

The code is as follows:

# remote Shell type is uncertain

$rsh $host "sh-c'$command; echo $?'"

Shell used to start the remote process

Because the type of Shell used to start the remote process is unknown, the syntax for some operations is different in different Shell.

For example, input and output redirection, command return value, and so on.

One way to solve this problem is to start the really needed mileage through an explicitly specified Shell. For example:

The code is as follows:

# unsure the type of remote Shell, explicitly use Bash Shell to start the required process

$rsh-n $host "sh-c'$command > / dev/null 2 > & 1'"

Another way of thinking is to start a real command through a wrapper program.

Execute background processes at the remote end through rsh

Want to execute background processes on the remote machine. The command rsh $host "$command &" does not work and will cause the local rsh process not to end.

The reason behind this should be that the standard input and output of $command is usually still bound to the socket of the rsh connection, thus preventing the local rsh process from reading to the file Terminator EOF.

If you know the reason, you will know what to do. The key is to close the background process to renew the standard input and output on the rsh connection.

The code is as follows:

# if the remote Shell is C Shell

$rsh-n $host "$command > & / dev/null &"

The code is as follows:

# if the remote Shell is Bash Shell

$rsh-n $host "$command > / dev/null 2 > & 1 &"

The code is as follows:

# uncertain type of remote Shell

$rsh-n $host "sh-c'$command > / dev/null 2 > & 1 &'"

But the drawback of the above redirection approach is that we can't get any output from the remote process, and sometimes we want to get some output information.

At this point, it is necessary for the remote process to be able to run as a daemon.

In this case, the rsh command can simply be written: $rsh-n $host "$command &"

The content of the remote background process is expressed in Tcl. The general idea is as follows:

The code is as follows:

# / bin/env tclsh

Puts "I am a background job"

Puts "This Can Be Seen by Remote rsh Process"

Close stdout

Close stderr

# rsh connection to this should end.

Puts "This Can NOT Be Seen by Remote rsh Process"

To go further, we can even ignore the background operator in the rsh command: $rsh-n $host "$command"

At this point, the remote process needs to end itself through fork and start the real background process (daemon).

Blocking and timeout handling of rsh processes

When calling rsh $host $command in a program, the rsh process may block for a variety of strange reasons, which is not what we want to see.

We want to set up a timeout mechanism to solve this problem.

An implementation in a Tcl program can be as follows: TODO

Rsh failure caused by too many TCP Connection connections

The monitoring email shows that the rsh $host $command command failed with an error message of "poll: protocol failure in circuit setup"

The suspicion is caused by too many network connections.

Network connection process of rsh $host $command

The command rsh $host connects to port 513 of the remote host.

The command rsh $host $command connects to port 514 of the remote host, and then sends a local port number to the remote host, asking the remote host to establish a new TCP connection to this port (it's not clear what this new connection will do). Then send the command and wait for the command to end.

The result is that when there are too many rsh $host $command processes, the locally open port resources are consumed, causing the new rsh $host $command to fail.

This is the use of rsh $host is still normal.

The shortcomings of rsh mentioned here are also one of the reasons why it is recommended to use ssh as much as possible.

A network connection that is not completely closed:

When the relevant rsh process is dropped by kill on the remote host, the TCP connection is not completely closed.

The netstat command shows the CLOSE_WAIT status, and the port resources are not released.

According to the configuration file / proc/sys/net/ipv4/tcp_keepalive_time, you need to wait 2 hours before those ports are actually shut down because of timeouts and are released.

The code is as follows:

% > netstat-a | grep localhost

Tcp 0 0 localhost:933 localhost:935 CLOSE_WAIT

% > cat / proc/sys/net/ipv4/tcp_keepalive_time

7200; # in seconds. = 2 hours

% > echo "net.ipv4.tcp_keepalive_time = 120" > > / etc/sysctl.con

At this point, I believe you have a deeper understanding of the "skills of using rsh remote shell commands in Linux". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.