Linux background task "Nohup/setsid/&/disown/screen"

In our daily development process, we may often manually do some scripts to organize data or perform some statistical tasks. While executing the script, we usually connect to the Linux server through an SSH terminal, and we can also execute the command or start the corresponding Script task through the SSH terminal. And this connection is usually unstable.

In this "unstable" network connection, if we perform some lengthy tasks or commands, the current task or command execution may be interrupted due to the shutdown of the SSH Terminal connection or other network reasons. And the next thing we want to talk about is how to solve this problem, so that the task can be in the background of the Linux server "silently" run, without being affected by the terminal. Here we will discuss the specific scenarios in several situations.

For a temporary background Script task that is not running:

1, Nohub command

The use of the Nohup command is very simple and convenient, just add nohup to the command to be processed, standard output and standard error The capital is redirected to the Nohup.out file in the current directory, that is, the file plays the role of monitoring log. In general, we can add "&" at the end of the command into the background to run, but also can use ">filename 2>&1" to change the default redirection file name (0, 1 and 2 respectively to represent standard input, standard output and standard error information output,> FileName: Redirect standard output to file filename, 2>&1: redirect error information to standard output. Examples of usage are as follows:

[root@pvcent107 ~]# nohup Ping www.ibm.com &
[1] 3059
nohup:appending output to ' nohup.out '
[root@pvcent107 ~]# ps-ef |grep 3059
Root 3059 984 0 21:06 pts/3 00:00:00 Ping www.ibm.com
Root 3067 984 0 21:06 pts/3 00:00:00 grep 3059
[Root@pvcent107 ~]#
2, Setsid command

The Nohup command can no doubt enable our process to avoid interruption midway by ignoring the HUP signal. But we can think of a different way, if our process does not belong to the HUP signal of the end of the process, then naturally will not be affected by the HUP signal. Setsid command will help us to do this. Examples of usage are as follows:

[root@pvcent107 ~]# setsid Ping www.ibm.com
[root@pvcent107 ~]# ps-ef |grep www.ibm.com
Root 31094 1 0 07:28? 00:00:00 Ping www.ibm.com
Root 31102 29217 0 07:29 pts/4 00:00:00 grep www.ibm.com
[Root@pvcent107 ~]#
3, & operator

We know that putting one or more names in "()" allows them to run in a child shell, extending a lot of interesting features, and we're going to talk about one of them now. When we put "&" in "()", we find that the submitted job (jobs) is not in the job list, that is, the job cannot be viewed through the jobs command. Usage examples:

[Root@pvcent107 ~]# (ping www.ibm.com &)
[root@pvcent107 ~]# ps-ef |grep www.ibm.com
Root 16270 1 0 14:13 pts/4 00:00:00 Ping www.ibm.com
Root 16278 15362 0 14:13 pts/4 00:00:00 grep www.ibm.com
[Root@pvcent107 ~]#
As can be seen from the example above, the parent ID (PPID) of the newly committed process is 1 (the PID of the Init process) and is not the process ID of the current terminal. Therefore, it does not belong to the current terminal's subprocess, so it is not affected by the HUP signal of the current terminal.

Ii. for tasks that have been committed and are in the process of being run:

1, Disown command

It is already too late to use the Nohup command or the SETSID command, which can only be solved by job scheduling and disown commands.

There are three common ways to operate the disown command:

Use disown-h Jobspec to make a job ignore the HUP signal.
Use Disown-ah to make all jobs ignore HUP signals.
Use DISOWN-RH to ignore the HUP signal for a running job.
Note that when the disown command is used, the target job is removed from the job list, and we will no longer be able to view it using the jobs command, but can still find it with the PS-EF command.

But there is a problem, this method is the operation of the object is the job, if we run the command at the end of the Add "&" to make it a job and run in the background, then it is all right, we can use the jobs command to get a list of all the jobs. But if you don't run the current command as a job, how do you get its job number? The answer is to use CTRL-Z (hold down the CTRL key while holding down the Z key)!

The use of ctrl-z is to suspend the current process (Suspend), and then we can use the Jobs command to query its job number, and then use BG Jobspec to put it back in the background and continue to run. Note that if the suspension affects the results of the current process, you should use this method with caution.

Example 1: (If a command is submitted with "&" to run in the background, you can use "disown" directly)

[root@pvcent107 build]# cp-r testlargefile Largefile &
[1] 4825
[Root@pvcent107 build]# Jobs
[1]+ Running cp-i-R testlargefile Largefile &
[root@pvcent107 build]# disown-h%1
[root@pvcent107 build]# ps-ef |grep largefile
Root 4825 968 1 09:46 pts/4 00:00:00 cp-i-R testlargefile Largefile
Root 4853 968 0 09:46 pts/4 00:00:00 grep largefile
[Root@pvcent107 build]# Logout
Example 2: (If you submit a command without using "&" to run the command in the background, you can use Ctrl-z and "BG" to put it back in the background, and then use "disown")

[root@pvcent107 build]# cp-r testlargefile largeFile2

[1]+ Stopped cp-i-R testlargefile LargeFile2
[root@pvcent107 build]# bg%1
[1]+ cp-i-R testlargefile LargeFile2 &
[Root@pvcent107 build]# Jobs
[1]+ Running cp-i-R testlargefile LargeFile2 &
[root@pvcent107 build]# disown-h%1
[root@pvcent107 build]# ps-ef |grep largeFile2
Root 5790 5577 1 10:04 pts/3 00:00:00 cp-i-R testlargefile LargeFile2
Root 5824 5577 0 10:05 pts/3 00:00:00 grep largeFile2
[Root@pvcent107 build]#
Third, for a large number of needs in the background stable operation of the task:

1. Screen command

Simply put, the screen command provides a ansi/vt100 terminal emulator that enables it to run multiple Full-screen pseudo terminals under a real terminal. The screen command has a lot of parameters and is very powerful, so we'll just introduce its common functions and briefly analyze why using screen can avoid the effects of HUP signals.

Using screen is convenient, with several common options:

Creates a session in disconnect mode (and specifies its session name) with the SCREEN-DMS sessions name.
Use Screen-list to list all sessions.
Screen-r session name to reconnect to the specified sessions.
Use the shortcut key Ctrl-a D to temporarily disconnect the current session.
Example:

[root@pvcent107 ~]# Screen-dms Urumchi
[Root@pvcent107 ~]# Screen-list
There is a screens on:
12842.Urumchi (Detached)
1 Socket in/tmp/screens/s-root.

[root@pvcent107 ~]# screen-r Urumchi
When we use "-r" to connect to the screen session, we can do anything in the pseudo terminal, and no longer need to worry about the HUP signal will affect our process, do not have to each command before adding "Nohup" or "Setsid". Why is that? Let me take a look at the following two examples.

1. A process tree with no screen for the newer process:

[root@pvcent107 ~]# Ping www.google.com &
[1] 9499
[root@pvcent107 ~]# pstree-h 9499
Init─┬─xvnc
├─acpid
├─atd
├─2*[sendmail]
├─sshd─┬─sshd───bash───pstree
│└─sshd───bash───ping
We can see that the bash we are in when we are not using screen is a sshd subprocess, and when SSH disconnects, the HUP signal naturally affects all of the child processes underneath it (including our newly established ping process).

2. The process tree of the new process after screen was used:

[root@pvcent107 ~]# screen-r Urumchi
[root@pvcent107 ~]# Ping www.ibm.com &
[1] 9488
[root@pvcent107 ~]# pstree-h 9488
Init─┬─xvnc
├─acpid
├─atd
├─screen───bash───ping
├─2*[sendmail]
Instead of using screen, bash is a child of screen, and screen is a subprocess of init (PID 1). Then when SSH disconnects, the HUP signal will naturally not affect the subprocess below screen.