Several reliable ways that Linux lets programs run in the background

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.

Let's start by introducing the name of Hangup.

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.

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?

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, the use of 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.

The use of nohup is very convenient, just add nohup before the command to be processed, standard output and standard error-deficient capital 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

Nohup Ping Baidu.com &

2. Setsid

Nohup can undoubtedly make our process avoid interruption 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 first.

Setsid Example setsid Ping baidu.com

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.

Using screen is convenient and has several common options:

Screen-s Yourname, a new session called Yourname
Screen-ls, List all current session
Screen-r yourname, back to yourname this session
screen-d yourname, remote detach a session
Screen-d-R Yourname End the current session and return to the session Yourname

Screen aborts a session

screen-S some_name -X quit

Screen Example

1. Create a new terminal called Yourname

Screen-s newname

2. Can run the command to execute

Ping baidu.com

3.c-a D-Detach, temporarily leave the current session, the current screen session (may contain multiple windows) to the background to execute, and will return to the status of not yet in screen, at this time in the screen session, each The process (either foreground/background) that runs within the window continues to execute, even if the logout is not affected.

Click to see more about screen operations

Original Connection Address

Several reliable ways that Linux lets programs run in the background