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

This article mainly introduces the example analysis of the reliable operation of the process in the background in Linux. The article is very detailed and has a certain reference value. Interested friends must read it!

Scene:

If there is only a temporary command that needs to be run for a long time, what is the easiest way to ensure that it runs steadily in the background?

Solution:

We know that when a user logs out (logout) or the network is disconnected, the terminal receives a HUP (hangup) signal and shuts down all its child processes. Therefore, 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 child process that does not belong to this terminal.

The origin of the name hangup

In earlier versions of Unix, each terminal communicated with the system through modem. When the user logout, modem will hang up (hang up) the phone. Similarly, when the modem is disconnected, it sends a hangup signal to the terminal to notify it to shut down all child processes.

1. Nohup

There is no doubt that nohup is the first way we think of. As the name implies, the purpose of nohup is to make submitted commands ignore hangup signals. Let's first take a look at nohup's help message:

NOHUP (1) User Commands NOHUP (1) NAME nohup-run a command immune to hangups, with output to a non-ttySYNOPSIS nohup COMMAND [ARG]. Nohup OPTION DESCRIPTION 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, as long as the command to be processed is preceded by nohup, and standard output and standard error are redirected to the nohup.out file by default. Usually 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 redirect file name.

Nohup example

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

2 、 setsid

There is no doubt that nohup can prevent our process from being interrupted by ignoring the HUP signal, but if we think about it another way, if our process is not a child process of the terminal that receives the HUP signal, then it will not be affected by the HUP signal. Setsid can help us do this. Let's first take a look at setsid's help message:

SETSID (8) Linux Programmer's Manual SETSID (8) NAME setsid-run a program in a new session SYNOPSIS 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, and 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.comroot 31094 10 07:28? 00:00:00 ping www.ibm.comroot 31102 29217 0 07:29 pts/4 00:00:00 grep www.ibm.com [root@pvcent107 ~] #

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), which is not the process ID of the current terminal. Compare this example with the parent ID in the nohup example.

3. Here is another tip about subshell. We know that including one or more names in a "()" allows these commands 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 will find that the submitted job is not in the job list, that is, it cannot be viewed through jobs. Let's see why we can avoid the influence of HUP signal in this way.

Subshell example

[root@pvcent107 ~] # (ping www.ibm.com &) [root@pvcent107 ~] # ps-ef | grep www.ibm.comroot 16270 10 14:13 pts/4 00:00:00 ping www.ibm.comroot 16278 15362 0 14:13 pts/4 00:00:00 grep www.ibm.com [root@pvcent107 ~] #

As you can see from the above example, the parent ID (PPID) of the newly committed 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, so it will not be affected by the HUP signal of the current terminal.

Disown

Scene:

We already know that if you add nohup or setsid before the command, you can avoid the influence of HUP signals. But if we have submitted the command without any processing, how can we remedy it so that it can avoid the influence of the HUP signal?

Solution:

By this time, it is too late to add nohup or setsid, and this problem can only be solved through job scheduling and disown. Let's take a look at disown's help message:

Disown [- ar] [- h] [jobspec...] Without options, each jobspec is removed from the table of active jobs. If the-h option is given, each jobspec is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If no jobspec is present, and neither the-a nor the-r option is supplied, the current job is used. If no jobspec is supplied, the-an option means to remove or mark all jobs; the-r option without a jobspec argument restricts operation to running jobs. The return value is 0 unless a jobspec does not specify a valid job.

It can be seen that we can achieve our goal in the following ways.

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 make running jobs ignore HUP signals.

Flexible use of CTRL-z

In our daily work, we can use CTRL-z to suspend the current process in the background, perform some other operations, and then use fg to put the suspended process back to the foreground (or you can use bg to put the suspended process in the background) to continue running. This gives us the flexibility to switch and run multiple tasks within a single terminal, which is especially useful when debugging code. Because when the code editor is suspended in the background and then put back, the cursor still stays in the position where it was last suspended, avoiding the trouble of repositioning.

It is important to note that after using disown, the target job will be removed from the job list, and we will no longer be able to use jobs to view it, but we can still find it with ps-ef.

But there is another problem. This method operates on jobs. If we add "&" at the end of the command to make it a job and run it in the background, then everything will be fine. We can use the jobs command to get a list of all 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 purpose of CTRL-z is to Suspend the current process, then we can use the jobs command to query its job number, and then use bg jobspec to put it in the background and continue to run. It is important to note that if suspending will affect the running results of the current process, please use this method carefully.

Disown example 1 (if you have already used "&" to run the command in the background 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 largeFileroot 4825 968 1 09:46 pts/4 00:00:00 cp-I-r testLargeFile largeFileroot 4853 968 0 09:46 pts/4 00:00:00 grep largeFile [root@pvcent107 build] # logout

Disown example 2 (if you submit a command without using "&" to run it in the background, 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 largeFile2root 5790 5577 1 10:04 pts/3 00:00:00 cp-I-r testLargeFile LargeFile2root 5824 5577 0 10:05 pts/3 00:00:00 grep largeFile2 [root@pvcent107 build] #

Screen

Scene:

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 to avoid doing this for every command?

Solution:

The most convenient method at this time is screen. To put it simply, screen provides a terminal emulator for ANSI/VT100, which enables it to run multiple full-screen pseudo-terminals under a real terminal. Screen has many parameters and powerful functions, so we will only introduce its common functions and briefly analyze why the use of screen can avoid the impact of HUP signals. Let's first take a look at screen's help message:

SCREEN (1) SCREEN (1) NAME screen-screen manager with VT100/ANSI terminal emulation SYNOPSIS screen [- options] [cmd [args]] screen-r [[pid.] tty [.host]] screen-r sessionowner/ [[pid.] tty [.host]] DESCRIPTION Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 standards (e.g. Insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows.

Screen is convenient to use, and there are several common options:

Use screen-dmS session name to establish a session in disconnected mode (and specify its session name).

Use screen-list to list all sessions.

Use screen-r session name to reconnect the specified session.

Use the shortcut CTRL-a d to temporarily disconnect the current session.

Screen example

[root@pvcent107] # screen-dmS Urumchi [root@pvcent107 ~] # screen-listThere is a screen on: 12842.Urumchi (Detached) 1 Socket in / tmp/screens/S-root. [root@pvcent107] # screen-r Urumchi

When we connect to the screen session with "- r", we can do whatever we want in this pseudo-terminal, no longer have to worry about the impact of HUP signals on our progress, or add "nohup" or "setsid" to every command. Why is that? Let me take a look at the following two examples.

1. The process tree of the new process when not using screen

[root@pvcent107] # ping www.google.com & [1] 9499 [root@pvcent107 ~] # pstree-H 9499init Xvnc acpid ├─ atd ├─ 2* [sendmail] ├─ sshd ─┬─ sshd ─── bash ─── pstree │ └─ sshd ─── bash ─── ping

We can see that when we are not using screen, the bash we are in is a child process of sshd. When ssh is disconnected, the HUP signal naturally affects all the child processes below it (including our newly established ping process).

two。 The process tree of the new process after using screen

[root@pvcent107 ~] # screen-r Urumchi [root@pvcent107 ~] # ping www.ibm.com & [1] 9488 [root@pvcent107 ~] # pstree-H 9488init ─┬─ Xvnc ├─ acpid ├─ atd screen ─── bash ─── ping ├─ 2* [sendmail]

This is different with screen, where bash is a child of screen and screen is a child of init (PID is 1). Then when the ssh is disconnected, the HUP signal naturally does not affect the child processes under the screen.

The above is all the contents of the article "sample Analysis of processes running reliably in the background in Linux". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.