Run and control Nginx
If my article has helped you, I will be very happy and welcome to follow me Github Welcome to my Blog , welcome star.
nginx command line parameters
Unlike many other software systems, Nginx has only a few command line parameters and is configured entirely through a configuration file
-c </path/to/config>Specify a configuration file for Nginx instead of the default.
-t does not run, just tests the configuration file.nginx checks the syntax of the configuration file and tries to open the file referenced in the configuration file.
-v Displays the version of nginx.
-V Displays the version of nginx, compiler version, and configuration parameters.
nginx control signal
You can use the signaling system to control the main process.By default, nginx writes the PID of its main process to the / usr/local/nginx/nginx.pid file.Change the location of the file by passing parameters to. /configure or using the PID directive.
The main process can process the following signals:
| signal | Effect |
|---|---|
| TERM, INT | Quick shutdown |
| QUIT | Easy shutdown |
| HUP | Overload the configuration, start a new worker process with the new configuration, and gracefully close the old worker process |
| USR1 | Reopen Log File |
| USR2 | Smooth upgrade executable. |
| WINCH | Close the worker process gracefully |
Although you don't have to work on your own processes, they also support some signals:
TERM, INT fast shutdown
QUIT Easy Shutdown
USR1 Reopen Log File
In Linux/Unix, signal a process with kill command, don't think Kill Command is only used to kill the process. It can send various signals to the process. Kill process only uses one of the SIGKILL signals. The format of kill command is as follows:
kill signal parameter process PID
The common signal parameters (English horizontal bar plus Arabic numerals) are as follows. For more signal information, you can use the man command to view the manual page (man 7 signal):
-1: This parameter represents the SIGHUP signal and acts like a restart process;
-2: This parameter represents the SIGINT signal, which acts as interrupting a process by typing Ctrl+C on the command line.
-9: This parameter represents the SIGKILL signal and represents a forced interruption of the process;
-15: This parameter represents the SIGTERM signal, indicating the normal termination process;
-17: This parameter represents the SIGSTOP signal, which is equivalent to inputting the Ctrl+Z key combination at the terminal to suspend the process.
nginx start, stop, restart commands
nginx startup
Sudo/usr/local/nginx/nginx (absolute path to nginx binary files, depending on your own installation path)
nginx calmly stop the command and shut down the service when all requests are finished
ps -ef |grep nginx kill -QUIT nginx #Main Process Number
Quick stop command for nginx, shut down nginx process immediately
ps -ef |grep nginx
Kill-TERM nginx main process number
Force Stop
Kill-9 nginx main process number
If you're not bothered, you can use the command instead of looking at the process number, where/usr/local/nginx/nginx.pid is the parameter set for the PID command in nginx.conf to store the file with the nginx main process number
kill - Signal Type (HUP|TERM|QUIT)
cat /usr/local/nginx/nginx.pid
for example
kill -QUIT `cat /usr/local/nginx/nginx.pid`
nginx restart command
- Simple, shut down the process, modify your configuration, and restart the process.
kill -QUIT cat /usr/local/nginx/nginx.pid sudo /usr/local/nginx/nginx
- Reload the configuration file, do not restart the process, do not stop processing requests
- Smoothly update nginx binaries without stopping processing requests
Load new configuration using signal
Nginx supports several signals and can control its operation while it is running.The most common of these is 15, which aborts a running process:
ps aux | egrep '(PID|nginx)' USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2213 0.0 0.0 6784 2036 ? Ss 03:01 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf kill -15 2213
The most interesting is the option to smoothly change the nginx configuration (note that you need to test the configuration file before overloading):
nginx -t -c /etc/nginx/nginx.conf
2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf syntax is ok
2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf was tested successfully
ps aux | egrep '(PID|nginx)'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2213 0.0 0.0 6784 2036 ? Ss 03:01 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
kill -HUP 2213
When nginx receives an HUP signal, it will try to parse the configuration file first (if a configuration file is specified, use the one specified, otherwise use the default), and if it succeeds, apply a new configuration file (for example, reopen the log file or listen on the socket).After that, nginx runs the new worker process and gracefully shuts down the old one.Notify the worker process to close the listening socket but continue to service the currently connected customer.Old worker processes are shut down when all client services are completed.If the new profile application fails, nginx will continue to work with the old configuration.
Smooth upgrade to new binary code
You can replace the old one with a new nginx executable (when upgrading a new version or adding/removing server modules) without interrupting the service - new requests will not be lost.
First, replace the old one with a new executable (preferably a good backup), then send a kill-USR2 PID signal to the main process.The main process renames its.Pid file to.Oldbin (for example, /usr/local/nginx/logs/nginx.pid.oldbin), then executes a new executable, starting a new main process and a new worker process in turn:
PID PPID USER %CPU VSZ WCHAN COMMAND 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx 33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) 33135 33126 nobody 0.0 1380 kqread nginx: worker process (nginx) 33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
At this point, the two nginx instances run simultaneously to process the input request together.To stop the old instance step by step, you must send a WINCH signal to the old main process, and then its working process will begin to shut down gracefully:
PID PPID USER %CPU VSZ WCHAN COMMAND 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx 33135 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx) 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
After a period of time, the old worker process has processed all connected requests and exited, and only the new worker process has processed the incoming requests:
PID PPID USER %CPU VSZ WCHAN COMMAND 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
At this time, because the old server has not closed the socket it is listening for, you can still restore the old server by following a few steps:
Send an HUP signal to the old main process - it will start its worker process without overloading the configuration file
Send a QUIT signal to the new master process, asking it to gracefully shut down its worker process
Send a TERM signal to the new main process, forcing it to exit
Send a KILL signal to a new worker process if for some reason it cannot exit
After the new main process exits, the old main process is restored to its.pid file by removing the.oldbin prefix, so everything is restored to its previous upgrade.
If the upgrade is successful and you want to keep the new server, send a QUIT signal to the old main process to exit leaving only the new server running:
PID PPID USER %CPU VSZ WCHAN COMMAND 36264 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)