Today’s article mainly introduces the reload process of nginx. In fact, in the previous article, when we change the nginx configuration file, we will execute the nginx – s reload command. The reason why we execute this command is that we hope that nginx will not stop the service, and always process new requests while smoothing out the old ones nginx.conf Configuration updated to new nginx.conf to configure.
Such a function is very necessary for nginx, but sometimes we find that it is being implemented
nginx -s reloadAfter the command, the number of worker subprocesses will increase. This is because the worker process running in the old configuration has not exited for a long time. When using stream as the four layer reverse proxy, this scenario may be more.
Now let’s explore what nginx has done by analyzing the reload process of nginx? What’s the difference between graceful exit and immediate exit?
The first step is to modify the configuration file of nginx nginx.conf After that, we send the HUP signal to the master process, which is actually the same as our execution on the command line
nginx -s reloadThe command effect is the same.
After receiving the HUP signal, the master process will check whether the syntax of our configuration file is correct in the second step. That is to say, we do not have to execute nginx – t before nginx – s reload to check whether the syntax is correct, because in the second step, the master process of nginx will certainly execute this step.
After the nginx configuration syntax is correct, the master process will open a new listening port. Why open a new listening port in the master process? Because we may be in nginx.conf A new listening port, such as 443, will be introduced in. All worker processes are the child processes of the master process. The child process will inherit all the open ports of the parent process. This is defined by the Linux operating system. So in the third step, the master process will open the new listening port that may be introduced.
Next, the Mster process uses the new nginx.conf Configuration file to start a new worker subprocess. What about the old worker subprocess?
In the fifth step, after starting a new worker subprocess, the master process will send the quit signal to the old worker subprocess. The quit signal is different from the term and int signals. The quit signal is to close the subprocess gracefully. At this time, we need to pay attention to the order. Because nginx needs to ensure smoothness, we need to start the new worker subprocess first, and then send the quit signal to the old worker The subprocess sends the quit signal.
After the old master subprocess receives the quit signal, it first closes the listening handle. That is to say, at this time, the new connection will only go to the new worker subprocess, so although there is a time difference between them, the time is very fast. After closing the listening handle and processing the current connection, it ends the process.
Next, see the figure of reload loading the new configuration without stopping.
Reload loading new configuration without downtime
There were four green worker subprocesses on the master process. They used the old configuration. When we changed the nginx.conf After configuring the file, send the signal of SIGHUP to the master or execute the command of reload. Then the master will start four new yellow worker subprocesses with the new configuration file. At this time, there are four old green worker subprocesses and four new yellow worker subprocesses Worker subprocesses coexist. Under normal circumstances, the old worker subprocess will close the connection after processing the request on the established connection, even if the connection is a keeplive request.
However, if some requests have problems and the client cannot handle them for a long time, the request will stay in the worker subprocess for a long time, and the worker subprocess will exist for a long time. Because the new connection has been running in the Yellow worker subprocess, the impact will not be great. The only one that will be affected is the green one The worker subprocess exists for a long time, but it only affects the existing connections, not the new ones.
What can we do about it? A new configuration worker is provided in the new version_ shutdown_ Timeout, that is, the longest waiting time. After the master process starts a new yellow worker process, if the old worker process does not exit, it will be forced to exit the old worker process when the time is up.
This paper mainly explains the process of nginx to smoothly upgrade the new configuration file. After we understand the relationship between gracefully closing the worker subprocess and starting the newly configured worker subprocess, we can better deal with rare exception scenarios.