Detailed explanation of Nginx process management and reloading principles

Process structure diagram

Nginx is a multi-process structure. The multi-process structure is designed to ensure high availability and reliability of Nginx, including:

• Master process: parent process, responsible for the management of worker processes
• Worker process: a child process. The worker process is generally configured with the same number of CPU cores as the server. The worker process is used to process specific requests.
• Cache process: It is also a sub-process, including cache manager and cache loader processes, which are mainly used as reverse proxy for caching.

Note: The reason why multi-process can guarantee high availability and high reliability compared to multi-threading is that the address spaces between processes are independent, and the tasks between processes will not affect each other. Compared with multi-threading, it consumes more CPU resources. Since multiple threads share the address space of a process, the failure of one thread task will affect the tasks of other threads.

Assuming that the user of our Nginx service is nginx, we can use the following command to view the master process and worker process of the currently running Nginx service, and we can see that the parent process ID of the four worker processes is the master's process ID (1325).

[root@master ~]# ps -ef | grep nginx | ​​grep -v grep | grep -v php-fpm
root 1325 1 0 11:28 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 1332 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1334 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1335 1325 0 11:28 ? 00:00:00 nginx: worker process
nginx 1336 1325 0 11:28 ? 00:00:00 nginx: worker process 

We can view our master and worker processes through lsof -i:nginx端口號.

[root@master ~]# lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1325 root 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1332 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1334 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1335 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1336 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)

Semaphore Management

Linux semaphore management mechanism

Signals are one of the ways of communication between processes. A typical usage is: a terminal user inputs an interrupt command to stop the running of a program through the signal mechanism.

We can manage our processes by sending signals to them. The kill -l command can view the semaphores supported by Linux.

There are 64 semaphores in total, and the following ones need to be clarified:

kill -1 $PID: (SIGHUP) reloads the process. For a daemon process that is disconnected from the terminal, this signal is used to notify it to reread the configuration file.

kill -2 $PID: (SIGINT) interrupt (via Ctrl+C);

kill -3 $PID: (SIGQUIT) exit from keyboard input (ctrl-\);

kill -9 $PID: (SIGKILL) kills the process immediately, regardless of the current state of the program;

kill -10 $PID: (SIGUSR1) $USR1 and $USR2 are both semaphores reserved for user-defined;

kill -12 $PID:($IGUSR2)

kill -15 $PID: (SIGTERM) normally stops a process;

kill -17 $PID: (SIGCHLD) The signal for communication between parent and child processes. The parent process can fork() many child processes. If a child process hangs up, a signal will be sent to the parent process.

kill can send the specified information to the program. The default message is SIGTERM(15), which terminates the specified program. If this still does not work, you can use the SIGKILL(9) message to try to forcibly remove the program. The program or job number can be viewed using the ps command or the jobs command.

kill -l # View all supported kill PID signals
# Kill a process kill 1024
# Kill multiple processes and separate the process numbers with spaces kill 1024 2048
# kill -9 means to force the process to end immediately kill -9 1024

Note: Ctrl+C: Stop the process running in the terminal. Ctrl+C can effectively terminate the program (process) running in the terminal.

Using semaphores to manage Nginx processes

Nginx processes can be managed in these ways: master進程, worker進程,命令行

Use semaphores to manage the master and worker processes (it is not recommended to use semaphores to manage the worker process; the worker process should be managed and maintained by the master process).

Master Process

Monitoring worker processes

• CHLD
  

Managing worker processes

Receiving Signals

• TERM, INT
• QUIT
• HUP
• USR1
• USR2
• WINCH

Example:

Kill the master process using the kill command

kill -s SIGTERM 1325

Use the kill command to let Nginx re-read the file, which will close the worker process and generate a new worker process. The master process (ID) remains unchanged.

kill -s SIGHUP 1325

Worker Process

Receiving Signals

• TERM, INT
• QUIT
• USR1
• WINCH

Although it is possible, it is not recommended to use semaphores to directly manage worker processes. Worker processes should be managed and maintained by the master process.

Example:

Use the kill command to kill a worker process. This will kill a worker process. Linux will send a SIGCHLD signal to the parent process (master process) of the killed worker process. Therefore, the master process detects that one of our child processes may have a problem and will start a new worker process to maintain the number of worker processes.

kill -s SIGTERM 1332

Command Line

• reload:HUP
• reopen：USR2
• stop：TERM
• quit：QUIT

You can use nginx -h to view the help command

[itbsl@master ~]$ nginx -h
nginx version: nginx/1.18.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h : this help
  -v : show version and exit
  -V : show version and configure options then exit
  -t : test configuration and exit
  -T : test configuration, dump it and exit
  -q : suppress non-error messages during configuration testing
  -s signal : send signal to a master process: stop, quit, reopen, reload
  -p prefix : set prefix path (default: /usr/local/nginx-1.18.0/)
  -c filename : set configuration file (default: conf/nginx.conf)
  -g directives : set global directives out of configuration file

Parameter Description:

• -?,-h: View help
• -v: Check Nginx version
• -V: View Nginx version and compilation options
• -t: Check whether the configuration file syntax is correct
• -T: Check whether the configuration file syntax is correct and print
• -q: Do not display non-error messages when checking configuration files
• -s: Send a signal to the master process, you can send: stop, quit, reopen, reload
• -c: Specify the configuration file
• -g: Set global directives outside the configuration file

Configuration file reloading principle

We know that we can upgrade nginx smoothly by sending a SIGHUP signal to the nginx master process or using the nginx -s reload command to reload the configuration file. So after we execute such a command, what happens behind the scenes for nginx itself? How does it ensure a smooth transition between new and old requests?

Reload the configuration file process

• Send a HUP signal to the master process (reload command)
• The master process checks whether the configuration syntax is correct
• The master process opens the listening port (possible if the port in the configuration file is modified)
• The master process starts a new worker subprocess using the new configuration file
• The master process sends a QUIT signal to the old worker child process
• The old worker process closes the listening handle and closes the process after processing the current connection.

If we use a diagram to describe it, it would look like this:

Graphic analysis:

1. The green status on the left is the status before executing the nginx -s reload command. According to the configuration of my personal host, there is one master process and four worker sub-processes.

2. In order to simulate that the original worker process will be killed after processing the request after executing the nginx -s reload command, I simulate an interface that takes a long time to complete the task and respond. Yes, I sleep for 15 seconds in the code, which means that it takes 15 seconds for this interface to respond. The longer time is convenient for us to observe the intermediate state. Note that the interface is requested before executing the reload command.

<?php
    sleep(15);
    echo json_encode(['msg' => 'hello world']);die();

3. We already know that the master process will hand over the task to the worker subprocess for processing. Currently there is only one task, so only one worker process needs to handle the task.

4. Execute the reload command, the master process will create 4 new worker processes (the yellow worker processes in the picture above) (depending on your configuration), and shut down the old idle worker processes (the green worker processes). The old worker processes that are processing requests will not be shut down immediately, but will be shut down after the requests are processed.

5. The last remaining old worker process is shut down after completing its task. The remaining ones are all new worker processes generated by the new nginx.conf configuration. You can see the picture below. The old worker process that is shutting down is still visible because it has not completed processing the task interface that sleeps for 15 seconds above.

Summarize

This is the end of this article about Nginx process management and overloading principles. For more information about Nginx process management and overloading principles, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!