Linux tips: several methods to make processes run reliably in the background

Article Title: Linux tips: several methods to make processes run reliably in the background. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

Do you want to keep the process running after it is disconnected? If the process has already started running, how can this problem be rectified? If there are a large number of such requirements, how can we simplify the operation?

We often encounter this problem. We use telnet/ssh to log on to a remote Linux server and run some time-consuming tasks. As a result, the task fails midway through due to network instability. After the command is submitted, how does one prevent the local terminal window/network disconnection? Here are some examples. You can select different methods for different scenarios to solve this problem.

Nohup/setsid /&

Scenario:

If a temporary command needs to be run for a long time, what method can be used to ensure its stable operation in the background?

Solution:

We know that when a user logs out or the network is disconnected, the supervisor will receive an HUP signal to close all its sub-processes. Therefore, our solution has two ways: either let the process ignore the HUP signal, or let the process run in a new session to become a child process that does not belong to this terminal.

1. nohup

Nohup is undoubtedly the first method we have come up. As the name suggests, nohup is used to make submitted commands ignore hangup (in earlier versions of Unix, every terminal communicates with the system through modem. When a user logs out, the modem hangs up. Similarly, when the modem is disconnected, it will send an hangup signal to the terminal to notify it to close all sub-processes .) Signal. Let's take a look at the help information of nohup:

NOHUP(1) User Commands NOHUP(1)NAME nohup - run a command immune to hangups, with output to a non-ttySYNOPSIS nohup COMMAND [ARG]... nohup OPTIONDESCRIPTION Run COMMAND, ignoring hangup signals. --help display this help and exit --version output version information and exit

It can be seen that nohup is very convenient to use. You only need to add nohup before the command to be processed. The standard output and standard error will be redirected to the nohup. out file by default. Generally, you can add "&" at the end to run the command in the background, or use "> filename 2> & 1" to change the default redirection file name.

 Nohup example

 

[Root @ pvcent107 ~] # Nohup ping www.ibm.com & [1] 3059 Nohup: appending output to 'nohup. out' [Root @ pvcent107 ~] # Ps-ef | grep 3059 Root 30599840 00:00:00 pts/3 ping www.ibm.com Root 3067 984 0 00:00:00 pts/3 grep 3059 [Root @ pvcent107 ~] #

 2. Setsid

Nohup can undoubtedly avoid interruption of our process by ignoring the HUP signal. However, if we think from another perspective that our process is not a sub-process of the terminal that accepts the HUP signal, then it will naturally not be affected by the HUP signal. Setsid can help us do this. Let's take a look at the help information of setsid:

SETSID(8) Linux Programmer’s Manual SETSID(8)NAME setsid - run a program in a new sessionSYNOPSIS setsid program [ arg ... ]DESCRIPTION setsid runs a program in a new session.

It can be seen that the use of setsid is also very convenient, you only need to add setsid before the command to be processed.

Setsid example

[Root @ pvcent107 ~] # Setsid ping www.ibm.com [Root @ pvcent107 ~] # Ps-ef | grep www.ibm.com Root 3109410 07:28? 00:00:00 ping www.ibm.com Root 31102 29217 0 00:00:00 pts/4 grep www.ibm.com [Root @ pvcent107 ~] #

In the preceding example, the process ID (PID) is 31094, and its parent ID (PPID) is 1 (that is, the init process ID ), it is not the process ID of the current terminal. Compare this example with the parent ID in the nohup example.

3. &
Here is also a tip about subshell. We know that the inclusion of one or more names in "()" allows these commands to run in the sub-shell, thus extending many interesting functions, we will discuss one of them now.

When we put "&" into "()", we will find that the submitted jobs are not in the job list, that is, they cannot be viewed through jobs. Let's take a look at why we can escape the influence of the HUP signal.

Subshell example

[Root @ pvcent107 ~] # (Ping www.ibm.com &) [Root @ pvcent107 ~] # Ps-ef | grep www.ibm.com Root 1627010 00:00:00 pts/4 ping www.ibm.com Root 16278 15362 0 00:00:00 pts/4 grep www.ibm.com [Root @ pvcent107 ~] #

From the above example, we can see that the parent ID (PPID) of the newly submitted process is 1 (PID of the init process) and is not the process ID of the current terminal. Therefore, it does not belong to the sub-process of the current terminal, so it will not be affected by the HUP signal of the current terminal.

[1] [2] [3] Next page