I still remember when I first developed the back-end service, I banged, the interface test passed, and the program was launched. Say to boss and front: my interface is deployed, you can test. Then the natural and unfashionable collect a package, flash a person, in the heart silently read a sentence: you this group of inefficient overtime dog. The front foot has not yet stepped out of the gate, hear “XXX, your interface is down”.

Returned to the seat to check the next, as expected cannot call, log on the server to view, the process did not, this is how? The guy next door took a look at my log and added “nohup &” to the start command, and everything was ok.

This was my first encounter with the nohup command, which I later learned would cause the program to ignore the HUP signal and keep the program running properly. When a terminal exits, it sends a SIGHUP signal to the process it is associated with, and upon receiving this signal, the process terminates. So you can ignore the signal if you don’t want the process to be killed by it. And that’s exactly what Nohup ordered to do. But how does it work?

Let’s look at two more concepts here: process groups and sessions.

Process group

A process group is a set of interrelated processes. Each process in the system must belong to a process group. Each process group has a unique PROCESS group ID(PGID). PGID is the same as the Process ID of the Process that created the Process group. This Process is also known as the Process group leader. All processes in the same Process group are children except the Process group leader. The existence of process groups makes it easier for the system to perform certain unified operations on multiple related processes. For example, we can send a semaphore to all processes in the same process group at once.

The session

A session is a collection of process groups. Similarly, each process group in the system must belong to a certain session. A session can have at most one (or none) control terminal, which is shared by all processes in all process groups in the session. There is only one front process group in a session, and only the processes in the front process group can interact with the control terminal. In addition to the foreground process group, process groups are background process groups; Similar to the process group leader, there is also the concept of a session leader, which represents the process that establishes and controls the terminal connection. In a session with a controlling terminal, the session leader is also called a controlling process. Generally speaking, the controlling process is the login shell process that logs in to the system.

After running the sleep background process sleep 50&, run the ps command to view the process and shell information as shown in the figure above:

•PPID indicates the id of the parent process. •PID indicates the process ID. •PGID indicates the process group ID. •SID indicates the session ID

SIGHUP trigger and default processing

Having understood the concept of a session, let’s now formally introduce the SIGHUP signal, which is sent at the end of a user terminal connection (normal or abnormal), usually at the end of the terminal’s control process, to notify the jobs in the same session that they are no longer associated with the control terminal. The default processing of SIGHUP signals is to terminate the process receiving the signal. So if the signal is not caught in the program, when the signal is received, the process will exit.

SIGHUP is sent to the process in one of three situations:

1. When the terminal is shut down, the signal is sent to the first process of the session and the process that submitted the job (that is, the process that submitted the job with the ampersand symbol). 2. When the first process of the session exits, this signal is sent to each process in the foreground process group of the session. 3. If the parent process exits and the processes in the orphan process group are stopped (SIGSTOP or SIGTSTP signals are received), a signal is sent to each process in the orphan process group.

Besides nohUP, is there any other way to prevent the HUP signal from causing the program to exit? The answer is the C library function sginal()

void (*signal(int sig, void (*func)(int)))(int)

Copy the code

Among them

• SIG — the signal number used as a variable in the signal handler. SIGHUP refers to the signal number •func – the processing function when the signal is received

We call this function to set a function to handle the signal, only print not exit can be done, the experimental code is as follows:

#include <stdio.h> #include <signal.h> #include <unistd.h> void handler(int a) { printf("hello\n"); } int main() { int i; signal(SIGHUP,handler); for(i=1; i<1000; i++){ printf("sleep %d ... \n",i); sleep(1); fflush(stdout); } return 0; }Copy the code

Let’s see how this works. Compile starts, then close the terminal

Open a new terminal and check whether the process is still running and whether the set signal handler has been called

The program did not exit, and hello output succeeded. In addition to using nohup, we can set up signal handlers in the code to achieve the same effect.

And there are some scenarios that we can’t directly use the default handler, such as high availability scenario, we need to use the way of a parent and child process, the parent process to monitor and maintain the start-stop and the expansion of the child process, some complex business logic, don’t want to be the user interrupt Ctrl + C, program USES a lot of external resources, needs in graceful exit recycling, etc. And a lot of good, mature programs do that, like postgreSQL

reference

• blog.csdn.net/z\_ryan/art…

• mp.weixin.qq.com/s/nyT-FPdIU…