Linux tips: Several ways to keep processes running reliably in the background

I used to be: Setsid

Usage: Setsid command #后面的命令是你正常执行的命令. For example, running in the background CS server: Setsid./team 127.0.0.1 Test

We often encounter such problems, log on to the remote Linux server with TELNET/SSH, run some long-time tasks, the result of the network instability caused by the task Midway failure. How do i make the command submit without being disturbed by the local shutdown of the terminal window/network disconnection? Here are some examples where you can choose different ways to handle this problem for different scenarios.

nohup/setsid/& Scene:

What is the easiest way to make sure it runs stably in the background if only a temporary command takes a long time to run?

Hangup the name of the

In earlier versions of Unix, each terminal was communicated via modem and system. When the user logout, the modem hangs up on the phone. Similarly, when the modem disconnects, it sends a hangup signal to the terminal to notify it to close all child processes.

Workaround:

We know that when the user logs off (logout) or the network disconnects, the terminal receives a HUP (hangup) signal to 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 to become a child process that does not belong to this terminal.

1. Nohup

Nohup is undoubtedly the way we think first. As the name implies, Nohup's purpose is to let the submitted command ignore the hangup signal. Let's take a look at Nohup's help information:

12345678910111213141516

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 the use of nohup is very convenient, just add nohup before the command to be processed, standard output and standard errors are redirected to the Nohup.out file. In general, we can add "&" at the end to run the command in the background as well as ">filename 2>&1" to change the default redirect file name.

nohup Example

1234567

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

2. Setsid

The

Nohup can undoubtedly prevent our process from being interrupted halfway by ignoring the HUP signal, but if we think in a different way, if our process is not part of the sub-process of the terminal receiving the HUP signal, then naturally it will not be affected by the HUP signal. Setsid can help us do that. Let's take a look at Setsid's help message:

12345678910

setsid (8)  & nbsp;               Linux Programmer ' s manual                 SETSID (8 )  name          setsid-run a program in a new session  < Code class= "Htmlscript plain" >synopsis          setsid program [arg ...]  description          setsid runs a program in a new session.

Visible Setsid is also very convenient to use, but also only need to deal with the command before adding Setsid can.

Setsid Example

12345

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

It is worth noting that our process ID (PID) in the example above is 31094, and its parent ID (PPID) is 1 (that is, the Init process ID), not the process ID of the current terminal. Compare this example to the parent ID in the nohup example.

3. &

Here's a little tip about Subshell. We know that the inclusion of one or more names in the "()" allows these commands to run in a child shell, which expands a lot of interesting functionality, and one of the things we're going to talk about right now.

When we put "&" into "()", we will find that the submitted job is not in the job list, that is, it cannot be jobs viewed. Let's see why it's possible to avoid the effects of HUP signals.

Subshell Example

12345

[[email protected] ~]# (ping www.ibm.com &)[[email protected] ~]# ps -ef |grep www.ibm.comroot     16270     1  0 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[[email protected] ~]#

As can be seen from the example above, 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.

Disown scene:

We already know that the effects of HUP signals can be avoided by adding nohup or setsid prior to the command. But if we have already submitted an order without any processing, how can we remedy it to avoid the effects of the HUP signal?

Workaround:

At this time to add nohup or setsid is too late, only through job scheduling and disown to solve the problem. Let's take a look at disown's help information:

1234567891011

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 -a    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.

As can be seen, we can achieve our goal in the following way.

Flexible use of ctrl-z

In our daily work, we can use the ctrl-z to suspend the current process to a background pause, perform some other action, and then use FG to back up the suspended process to the foreground (or BG to put the pending process in the background) to continue running. This allows us to flexibly switch between running multiple tasks within one terminal, which is especially useful when debugging code. Since the code editor is suspended to the background and then re-placed back, the cursor position remains at the location of the last suspension, avoiding the hassle of repositioning.

• Use to make disown -h jobspec a job ignore the HUP signal.
• Use disown -ah  to make all jobs ignore the HUP signal.
• Use disown -rh  to make the running job ignore the HUP signal.

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

However, there is a problem, the operation of this method is the job, if we run the command at the end of the "&" to make it a job and run in the background, then it is all right, we can jobs get a list of all jobs by command. But if the current command is not running as a job, how can I 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 (Suspend), then we can use the jobs command to query its job number, then use bg jobspec it to put it in the background and continue to run. It is important to note that this method is used with caution if the suspension affects the running results of the current process.

Disown Example 1 (You can use "disown" directly if you have already used "&" to run the command in the background when you submit the command)

123456789

[[email protected] build]# cp -r testLargeFile largeFile &[1] 4825[[email protected] build]# jobs[1]+  Running                 cp -i -r testLargeFile largeFile &[[email protected] build]# disown -h %1[[email protected] 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[[email protected] build]# logout

Disown Example 2 (if the command was submitted without using "&" to run it in the background, you can use Ctrl-z and "BG" to put it in the background and use "disown")

123456789101112

[[email protected] build]# cp -r testLargeFile largeFile2[1]+  Stopped                 cp -i -r testLargeFile largeFile2[[email protected] build]# bg %1[1]+ cp -i -r testLargeFile largeFile2 &[[email protected] build]# jobs[1]+  Running                 cp -i -r testLargeFile largeFile2 &[[email protected] build]# disown -h %1[[email protected] 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[[email protected] build]#

Screen scene:

We already know how to keep the process free of HUP signals, but if there are a lot of such commands that need to be run in a stable background, how do you avoid doing this for every command?

Workaround:

The most convenient way to do this is screen. Simply put, screen provides the ansi/vt100 terminal emulator, which enables it to run multiple full screens of pseudo-terminals under a real terminal. Screen has a lot of parameters and is very powerful, so we'll just describe its common functions and briefly analyze why using screen can avoid the effects of HUP signals. Let's take a look at screen's help information:

12345678910111213141516171819

SCREEN(1)                                                           SCREEN(1)NAME       screen - screen manager with VT100/ANSI terminal emulationSYNOPSIS       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.

Using screen is convenient and has several common options:

• Use screen -dmS session name to create a session in disconnected mode (and specify its session name).
• Use screen -list  to list all sessions.
• Use screen -r session name to reconnect to the specified session.
• Use the shortcut key CTRL-a d  to temporarily disconnect the current session.

Screen Example

1234567

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

When we connect to the screen session with "-R", we can do anything in this pseudo-terminal, no longer worry about the HUP signal will affect our process, and do not have to add "nohup" or "setsid" before each command. What is this for? Let me take a look at the following two examples.

1. Process tree without using the screen's newly process

123456789

[[email protected] ~] # ping www.google.com & [1] 9499 [[ Email protected] ~]# pstree-h 9499 init─┬─xvnc       ├─acpid       ├─atd       ├─2*[sendmail] Code class= "Htmlscript spaces" >      ├─sshd─┬─sshd───bash───pstree       │      └─sshd───bash───ping

As we can see, the bash we're in when we're not using screen is an sshd subprocess, and when SSH disconnects, the HUP signal naturally affects all of the sub-processes underneath it (including our newly created ping process).

2. Process tree using the new process after screen

123456789

[[email protected] ~]# screen-r Urumchi [[email protected] ~]# ping www.ibm.com & [1] 9488 [[email protected] ~]# pstree-h 9488 init─┬─xvnc        ├─acpid        ├─atd        ├─screen───bash───ping       ├─2*[sendmail]

Instead of using screen, bash is the child process of screen, and screen is the child of Init (PID 1). Then when SSH disconnects, the HUP signal naturally does not affect the sub-processes under screen.

Summarize

Now that several methods have been introduced, we can choose different scenarios according to different scenarios. Nohup/setsid is undoubtedly the most convenient method for temporary needs, disown can help us to remedy the job that is currently running, and screen is the choice of a large batch operation.

Linux tips: Several ways to keep processes running reliably in the background