Explore the truth behind the reload process in Nginx

Today's article mainly introduces the reload process of Nginx. In fact, in the previous article, when we changed the nginx configuration file, we would execute the nginx -s reload command. The reason for executing this command is that we hope that nginx will not stop the service and always process new requests while smoothly updating the nginx configuration file from the old nginx.conf configuration to the new nginx.conf configuration.

Such a function is very necessary for nginx, but sometimes we will find that after executing nginx -s reload command, the number of worker subprocesses will increase. This is because the worker process running with the old configuration has not exited for a long time. When using stream as a four-layer reverse proxy, this scenario may be more common.

So let's analyze the reload process of nginx to explore what nginx does. What is the difference between a graceful exit and an immediate exit?

Reload Process

The first step is to send a HUP signal to the master process after modifying the nginx configuration file nginx.conf. This is actually the same as executing the nginx -s reload command on the command line.

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 necessarily have to execute nginx -t to check whether the syntax is correct before nginx -s reload, because the master process of nginx will definitely execute this step in the second step.

After the configuration syntax of nginx is correct, the master process will open a new listening port. Why should a new listening port be opened in the master process? Because we may introduce new listening ports such as 443 or previously unopened listening ports in nginx.conf, and all worker processes are child processes of the master process, and child processes inherit all opened ports of the parent process. This is defined by the Linux operating system, so in the third step, our master process opens the new listening ports that may be introduced.

Next, the master process will use the new nginx.conf configuration file to start a new worker subprocess, so what will happen to the old worker subprocess?

In the fifth step, after starting a new worker child process, the master process will send a QUIT signal to the old worker child process. The QUIT signal is different from the TERM and INT signals. The QUIT signal is to close the child process gracefully. At this time, you need to pay attention to the order, because nginx needs to ensure smoothness, so you need to start a new worker child process first, and then send a QUIT signal to the old worker child process.

Then after the old master child process receives the QUIT signal, it first closes the listening handle. That is to say, at this time, new connections will only go to the new worker child process. So although there is a time difference between them, the time is very fast. Then after closing the listening handle, the process ends after processing the current connection.

Below is a diagram showing how reload loads a new configuration without stopping the machine.

reload loads new configuration without stopping

There were originally four green worker sub-processes on the master process, which used the old configuration. When we changed the nginx.conf configuration file, we sent a SIGHUP signal to the master or executed a reload command. Then the master started four new yellow worker sub-processes with the new configuration file. At this time, the four old green worker sub-processes and the four new yellow worker sub-processes coexisted. Then the old worker child process will normally close the connection after processing the request on the established connection, even if the connection is a keeplive request.

However, in abnormal situations, if some requests have problems and the client cannot process them for a long time, the request will remain in the worker sub-process for a long time. In this case, the worker sub-process will exist for a long time. Because the new connection is already running in the yellow worker sub-process, the impact will not be significant. The only thing that will be affected is that the green worker sub-process will exist for a long time, but it will only affect the existing connections and not the new connections.

What can we do about it? The new version provides a new configuration worker_shutdown_timeout, which means the maximum waiting time. In this way, after the master process starts a new yellow worker process, if the old worker process has not exited, the old worker process will be forced to exit after the time is up.

Summarize

This article mainly explains the process of Nginx smoothly upgrading the new configuration file. After we understand the relationship between gracefully shutting down the worker subprocess and starting the newly configured worker subprocess, we can better handle rare abnormal scenarios.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.