Unlike many other software systems, nginx only has several command line parameters and is configured in the configuration file (IMAGINE ).
[# Options]
[# Example]
[# Using signals to load new configurations]
[# Upgrade utnbotf to new binary code]
Option
-C </path/to/config> specifies a configuration file for nginx to replace the default one.
-T does not run, but only 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 nginx version.
-V displays the nginx version, compiler version, and configuration parameters.
Example
This example only tests whether the configuration file at the specified location is normal and provides a prompt.
/Usr/bin/nginx-t-c ~ /Mynginx. conf
Start the nginx batch file in Windows (provided by somaceo). Download process.exeand runhiddenconsole.exe on the network and put them in the nginx installation directory, and create a nginx Startup File. the bat file contains the following content. You can modify the path and other address parameters according to your actual situation.
@ Echo offcd nginx> nulecho is stopping nginxprocess .....process.exe-K nginx.exe> nulecho is stopping the PHP (FastCGI) process... Rem process.exe-K php-cgi.exe> nulecho nginx + PHP has stopped. @ Echo offcd nginx> nulecho is starting the PHP (FastCGI) process ...... the echo PATH uses the relative path relative to the processing file of this batch. (You can also use the absolute path, but it is not conducive to copy and migration.) Specify the reference address: Port, and load PHP at a specific location. INI file. If you don't need PHP, you can ignore it. Runhiddenconsole.exe... \ PHP \ php-cgi.exe-B 127.0.0.1: 9000-C .. \ PHP. iniecho PHP started. Echo nginx checks the syntax of the specified configuration file and tries to open the file referenced in the configuration file. Nginx.exe-t-c CONF/nginx. confecho-V displays the nginx version. For details about the size of the vword, see: http://wiki.nginx.org/NginxChsCommandLinenginx.exe-vecho next start nginx process... echo is starting nginxprocess .....nginx.exe-c conf/nginx. confecho nginx + PhP started. Rem uses pause to pause and retain command window to see if there is any error in pauseexit
Control nginx through System Signal
You can use a signal system to control the main process. By default, nginx writes the PID of the main process to the/usr/local/nginx/logs/nginx. PID file. You can change the file location by passing the parameter to./configure or using the PID command.
The main process can process the following signals:
Quickly disable term and int
Close quit
Hup reload Configuration
Start a new working process with a new configuration
Close old working processes with ease
Usr1 re-open the log file
Usr2 smoothly upgrades executable programs.
Winch calmly closes the Working Process
Although you do not have to operate the Worker Process on your own, they also support some signals:
Quickly disable term and int
Close quit
Usr1 re-open the log file
Template: Anchor
Use signals to load new configurations
Nginx supports several signals and can control its operations during its operation. The most common process is 15, which is used to stop the running process:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 2213 0.0 0.0 6784 2036 ? Ss 03:01 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
The most interesting thing is that you can smoothly change the nginx configuration options (note that you should test the configuration file before reloading ):
2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf syntax is ok2006/09/16 13:07:10 [info] 15686#0: the configuration file /etc/nginx/nginx.conf was tested successfullyUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 2213 0.0 0.0 6784 2036 ? Ss 03:01 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
When nginx receives the HUP signal, it will first parse the configuration file (if the configuration file is specified, it will use the specified one; otherwise, the default one will be used, apply the new configuration file (for example, re-open the log file or listen to the socket ). Then, nginx runs the new working process and closes the old working process with ease. Notify the working process to close the listening socket but continue to provide services for the customers currently connected. After the services of all clients are completed, the old working process is disabled. If the application of the new configuration file fails, nginx will continue to work with the old configuration.
RequestForReviewCategory -- (Request For Review: Just What Happens With The Worker Processes at a HUP? -Olle)
Smooth upgrade to new binary code
You can-new requests will not be lost without service interruption, and replace the old ones with the new nginx executable program (when upgrading the new version or adding/deleting the server module ).
First, replace the old one with the new executable program (preferably back up), and then send the usr2 (kill-usr2 PID) signal to the main process. The main process will rename it. PID file is. oldbin (for example,/usr/local/nginx/logs/nginx. PID. oldbin), and then execute the new executable program to start the new master process and the new worker process in sequence:
PID PPID USER %CPU VSZ WCHAN COMMAND33126 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) </pre>
At this time, the two nginx instances run simultaneously to process input requests together. To gradually stop the old instance, you must send a winch signal to the old master process. Then, its working process will start to close calmly:
: PID PPID USER %CPU VSZ WCHAN COMMAND33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx33135 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/nginx36265 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 processes all connected requests and then exits. The new worker processes only process the input requests:
: PID PPID USER %CPU VSZ WCHAN COMMAND33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx36265 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 its listening socket, you can still restore the old server through the following steps:
Send an HUP signal to the old master process-it will start its working process without reloading the configuration file
Send a quit signal to the new master process and ask it to close its working process with ease
Send a term signal to the new master process to force it to exit
If a new worker cannot exit for some reason, send a kill signal to it
After the new master process exits, the old master process will be restored to its. PID file by removing the. oldbin prefix, so that everything will be restored to the upgrade.
If the upgrade is successful and you want to retain a new server, send a quit signal to the old master process to exit the server, 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)