Cause Analysis and nohup usage for disabling background processes on Linux terminal

Cause Analysis and nohup usage for disabling background processes on Linux terminal

Windows and Linux Remote connections (both called remote connections) are different:

1) after Windows Remote connection, if you run a program on a remote machine, you can log out of the connection and connect to the machine for a while to see if the connection has ended, that is to say, without any processing, the program running on the remote machine will not end with the disconnection.

2) After Ubuntu logs on to the remote host and runs the program, if the connection is terminated and exited, all processes running in the session opened by the connection will be killed, that is, the program running remotely ends with the connection being aborted.

Windows is easy to use. If Ubuntu is in use, it will be much easier to achieve the Windows response feature.

In Ubuntu, this is mainly because:

1) related concepts of processes:

In Linux, each process belongs to a process group with a group leader. Multiple processes are grouped into one session, which is created by the process, this process is called the session leader ). The session leader's PID is the session ID ). Each process group in a session is called a job ). A session can contain a foreground job, while other process groups are background jobs ). Not every process in the process group is the content of the job. The job is composed of the "son" of the session process. However, when the process in the job generates a sub-process, the sub-process is not the content in the job.

Each session can be connected to a control terminal ). When the control terminal has input and output, all are passed to the foreground Process Group of the session. After the last process in the current process group or job is completed, the background session control process automatically switches to the front end. Signals generated by the terminal, such as CTRL + Z, CTRL + \, will be passed to the foreground process group.

A session is mainly created for a terminal. When we open multiple terminal windows, we actually create multiple terminal sessions. Each session has its own foreground and background work. In this way, we add a management and operation level for the process.

2) concepts related to terminals:

In a UNIX system, a user logs on to the system through a Terminal and obtains a Shell process. The Terminal becomes the Controlling Terminal of the Shell process. The control Terminal is the information stored in the PCB, we know that fork will copy information in the PCB, so the control terminal of other processes started by the Shell process is also the terminal. By default (no redirection), the standard input, standard output, and standard error output of each process point to the control terminal. The process reads from the standard input, that is, the user's keyboard input, the process writes to the standard output or standard error output, that is, the output to the display. Enter some special control keys on the control terminal to send signals to the foreground process. For example, Ctrl-C Indicates SIGINT and Ctrl-Indicates SIGQUIT.

Each process can access its control terminal through a special device file/dev/tty. In fact, each terminal device corresponds to a different device file./dev/tty provides a common interface, A process can access its control terminal either through/dev/tty or through the device file corresponding to the terminal device. The ttyname function can be used to identify the corresponding file name by the file descriptor. The file descriptor must point to a terminal device rather than any file. The tty command on linux can also view the current terminal. For example, opening a terminal in the graphic interface may be/dev/pts/0, and the second may be/dev/pts/1 .. (network terminal), while switching to the character interface may be/dev/tty1... (virtual terminal)

3) processes and terminals:

After logging on to the system through a terminal, the user obtains a Shell Process. The Shell is divided into the frontend and backend to control not processes but jobs or Process groups ). A foreground job can be composed of multiple processes, and a background job can also be composed of multiple processes. Shell can run a foreground job and any number of background jobs at the same time, this is called JobControl ). For example, run the following command to start five processes (this example is from APUE ):
$ Proc1 | proc2 &

$ Proc3 | proc4 | proc5

Proc1 and proc2 belong to the same background process group, proc3, proc4, and proc5 belong to the same foreground process group, and the Shell process itself belongs to a separate process group. The control terminals of these process groups are the same. They belong to the same Session. A Session is related to a control terminal. When you enter a special control key (for example, Ctrl-C) on the control terminal, the kernel sends a signal (for example, SIGINT) to all processes in the foreground process group. Shows the relationship between processes, Process Groups, and sessions.

In the preceding example, proc3, proc4, and proc5 are put in the same frontend process group by Shell. One of the processes is the Leader of the Process Group, and Shell calls wait to wait for them to finish running. Once all of them are finished, Shell calls the tcsetpgrp function and mentions it to the foreground to continue to accept the command. However, if a process in proc3, proc4, and proc5 forks out sub-processes, the sub-processes also belong to the same process group, but the Shell does not know the existence of the sub-process, it will not call wait to wait for it to end. In other words, proc3 | proc4 | proc5 is a Shell job, but this sub-process is not. This is a conceptual difference between a job and a process group. Once the job finishes running, Shell will introduce itself to the foreground. If the original foreground process group still exists (if the child process has not been terminated), it will automatically become a background process, taken over by the init process.

A common process (except a daemon) in Linux is a sub-process of a terminal. The existence of a process depends on the space provided by the terminal, including standard input, standard output, and standard error. When the initial process (namely the SID process) that opens the terminal exits, its sub-process also ends.

4) Terminal logon and Command Execution Process:

Now we can review the process of logging on to and executing commands from the perspective of Session and process group.

Before the getty or telnetd process opens the terminal device, it calls the setsid function to create a new Session, which is called the SessionLeader. the id of the process can also be considered as the Session id, the process then opens the terminal device as the control terminal for all processes in the Session. A new Process Group is created when a new Session is created. The Process is the Process Group Leader of the Process Group. The Process id is also the id of the Process Group.

During the login process, the getty or telnetd process becomes login and Shell, but it is still the same process and still the Session Leader.

The sub-processes (such as p3, p4, and p5 in the preceding example) generated by the Shell process fork have the same Session, process group, and control terminal as the Shell, however, Shell calls the setpgid function to specify a sub-process in the job as the Leader (such as p3) of a new process group ), call setpgid to transfer other sub-processes in the job to the process group. If this process group needs to run on the foreground, call the tcsetpgrp function to set it as the foreground process group. Since a Session can only have one foreground process group, therefore, the process group where the Shell is located is automatically changed to the background process group.

5) How to exit the process and continue execution

In Unix/Linux, for example, if you want a program to run in the background, many of them use & to make the program run automatically at the end of the program. Maybe our program is just a common program (not a daemon process). Generally, this program uses and ends, but if the terminal is closed, the program will also be closed.

You can use the nohup command to execute the program in the background and run the program after the terminal exits:

Nohup make &

At this time, the screen prompts:

[~] $ Appending output to nohup. out

Verify that the program runs successfully and put the output information of the program running in the nohup. out file of the current directory.

Remember to use the normal exit method when exiting the terminal, instead of directly shutting down putty or other terminal login programs, you should exit in the session. This is pending.

Appendix: nohup command reference

Nohup command

Purpose: run the command without hanging up.

Syntax: nohup Command [Arg...] [&]

Description: The nohup Command runs the Command specified by the Command parameter and any relevant Arg parameter, ignoring all SIGHUP signals. After logging out, run the nohup command to run the program in the background. To run the nohup command in the background, add the & (symbol indicating "and") to the end of the command.

Whether or not the output of the nohup command is redirected to the terminal, the output will be appended to the nohup. out file in the current directory. If the nohup. out file in the current directory cannot be written, the output will be redirected to the $ HOME/nohup. out file. If no file can be created or opened for append, the Command specified by the Command Parameter cannot be called. If a standard error is a terminal, write the specified command to all outputs of the standard error as the standard output and redirect it to the same file descriptor.

For other methods, refer to making Linux processes unaffected by terminals.