Detailed explanation of three methods on how to make processes run in the background in Linux

We often encounter this problem. We want to run some long-term tasks on the Linux server, but the task fails midway due to network instability. How to prevent the command from being interfered by closing the terminal window locally/disconnecting the network after the command is submitted?

The following are three methods that can easily meet the above needs.

Problem Analysis:

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

Three solutions:

1. nohup

nohup is undoubtedly the first solution we think of. As the name suggests, the purpose of nohup is to make the submitted command ignore the hangup signal.

The use of nohup is very convenient. Just 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, we can add "&" at the end to run the command in the background at the same time, or we can use ">filename 2>&1" to change the default redirection file name.

nohup example

[root@pythontab ~]# nohup ping www.pythontab.com &
[1] 3059
nohup: appending output to `nohup.out'
[root@pythontab ~]# ps -ef |grep 3059
root      3059   984  0 15:06 pts/3    00:00:00 ping www.pythontab.com
root      3067   984  0 15:06 pts/3    00:00:00 grep 3059
[root@pythontab ~]#

2. setsid

nohup can undoubtedly prevent our process from being interrupted midway by ignoring the HUP signal, but if we think about it from another angle, if our process does not belong to the terminal that accepts the HUP signal Child process, then naturally it will not be affected by the HUP signal. setsid helps us do this.

setsid is also very convenient to use. You only need to add setsid before the command to be processed.

setsid example

[root@pythontab ~]# setsid ping www.pythontab.com
[root@pythontab ~]# ps -ef |grep www.pythontab.com
root     31094     1  0 07:28 ?        00:00:00 ping www.pythontab.com
root     31102 29217  0 07:29 pts/4    00:00:00 grep www.pythontab.com
[root@pythontab ~]#

It is worth noting that in the above example, our process ID (PID) is 31094, and its parent ID (PPID) is 1 (that is, init Process ID), not the process ID of the current terminal.

3. & subshell

Here is another little tip about subshell. We know that including one or more names in "()" allows these commands to be run in a subshell, thus extending many interesting functions, one of which we are going to discuss now.

When we put "&" inside "()", we will find that the submitted job is not in the job list, that is to say, it cannot pass jobs Came to check it out. Let’s take a look at why this works to avoid the HUP signal.

subshell example

[root@pythontab ~]# (ping www.pythontab.com &)
[root@pythontab ~]# ps -ef |grep www.pythontab.com
root     16270     1  0 16:13 pts/4    00:00:00 ping www.pythontab.com
root     16278 15362  0 16:13 pts/4    00:00:00 grep www.pythontab.com
[root@pythontab ~]#

As can be seen from the above example, the parent ID (PPID) of the newly submitted process is 1 (the PID of the init process), which is not the process ID of the current terminal. Therefore, it does not belong to the child process of the current terminal, and thus will not be affected by the HUP signal of the current terminal.

Comparatively speaking, I prefer to use setsid, which is simple and practical. Of course, it depends on everyone's preference here, and there is not much difference in effect.

The above is the detailed content of Detailed explanation of three methods on how to make processes run in the background in Linux. For more information, please follow other related articles on the PHP Chinese website!