I. nohup/setsid/&
Use scenarios:
If only a temporary command takes a long time to run, what is the easiest way to ensure that it runs stably in the background?
There are two ways to solve this problem: either let the process ignore the HUP signal, or let the process run in a new session and become a sub-process that does not belong to this terminal.
Solution:
1.nohup
Just add nohup before the command you need to process, and standard output and standard errors are 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 redirected file name.
[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
Setsid is also very convenient to use, and only need to add setsid before the command to be processed.
[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 ~]#
In the example above, our process ID(PID) is 31094, while its parent ID (PPID) is 1 (i.e. init process ID), which is not the process ID of the current terminal. Compare this example with the parent ID in the nohup case.
3. &
Including one or more names in "()" allows these commands to run in a subshell
When we put "&" in "()", we will find that the submitted jobs are not in the list of jobs, that is to say, they can not be viewed through jobs.
[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 ~]#
The parent ID (PPID) of the newly submitted process is 1 (PID of init process), 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.
Two. disown
Use scenarios: If nohup or setsid is added before the command, the HUP signal can be avoided. But if we have submitted the order without any processing, how can we remedy it to avoid the impact of the HUP signal?
Solution: It's too late to add nohup or setsid. Job scheduling and disown are the only ways to solve this problem.
Disown-h job spec is used to make a job ignore the HUP signal.
Disown-ah is used to make all jobs ignore HUP signals.
Disown-rh is used to make the running job ignore the HUP signal.
After using disown, the target job will be removed from the job list. We will no longer be able to view it with jobs, but we will still be able to find it with ps-ef.
Ex amp le 1 of disown (if the command has been put in the background with "&" when submitting the command, 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
Ex amp le 2 of disown (if the command is not run in the background using "&" when submitting the command, you can use CTRL-z and "bg" to put it 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]#
3:screen
Use scenarios:
We already know how to protect processes from HUP signals, but if there are a large number of such commands that need to be run in a stable background, how can we avoid doing this for each command?
Solution:
The most convenient way to do this is screen. Simply put, screen provides ANSI/VT100 terminal simulator, which enables it to run multiple full-screen pseudo-terminals in a real terminal. Screen has many parameters and powerful functions.
Use screen-dmS (session Name) to create a session in disconnected mode (and specify its session name).
List all sessions with screen-list.
Use screen-r (session Name) to reconnect the specified session.
Use the shortcut key CTRL-a d to temporarily disconnect the current session.
screen example
[root@pvcent107 ~]# screen -dmS Urumchi [root@pvcent107 ~]# screen -list There is a screen on: 12842.Urumchi (Detached) 1 Socket in /tmp/screens/S-root. [root@pvcent107 ~]# screen -r Urumchi
When we connect to screen session with'-r', we can do whatever we want in this pseudo-terminal. We don't have to worry about the impact of the HUP signal on our process anymore. We don't have to add "nohup" or "setsid" before each command.
The process tree of the new process when screen is not used
[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
When screen is not used, our bash is a sub-process of sshd. When ssh disconnects, the HUP signal will naturally affect all the sub-processes below it (including our newly established ping process).
The process tree of the new process after screen is 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]
When screen is used, bash is a child of screen, and screen is a child of init (PID 1). Then when ssh disconnects, the HUP signal naturally does not affect the sub-processes under screen.