Installation and use of nginx in CentOS system

Install nginx
under centos
The requirements for compiling Nginx are as follows:
Disk space: It is necessary to ensure that there is more than 10MB of free disk space. After Nginx is installed, it will occupy about 4MB of disk space. The actual disk space requirements will vary depending on the compilation settings and whether third-party modules are installed.
GCC compiler and related tools: GCC is called GNU Compiler Collection,
It is a powerful and high-performance free compiler for programming development launched by the GNU community. It is one of the representative works of GNU. Currently, the languages ​​that can be compiled include: C, C++, Objective-C, Fortran, Java, etc. You must ensure that your operating system has a GCC compiler installed.
In addition, you must also install the Autoconf and Automake tools, which are used to automatically create complete Makefiles. Most current software packages use this tool to generate Makefiles, and Nginx is no exception. Under the CentOS system, you can use the yum command to install the GCC compiler and related tools:
yum -y install gcc gcc-c++ autoconf automake
Module dependency: Some modules of Nginx need the support of other third-party libraries, such as gzip module needs zlib library, rewrite module needs pcre library, ssl function needs openssl library, etc. Similarly, if it is under the CentOS system, we can use the yum command to install or download the source package to compile and install the libraries that these modules depend on:
yum -y install zlib zlib-devel openssl openssl –devel pcre
pcre-devel
Nginx can be installed in the Linux environment by compiling the source code. The simplest installation command is as follows:
tar zxvf nginx-version.tar.gz
cd nginx-version-number
./configure
make
make install
According to the above command, Nginx will be installed in the /usr/local/nginx directory by default. You can pass /configure
–helpCommand to view the compilation options that Nginx can choose.
Examples of compilation options are as follows:
–prefix=
Nginx installation path. If not specified, defaults to /usr/local/nginx
–sbin-path=
Nginx executable file installation path. It can only be specified during installation, if not specified, the default is /sbin/nginx
–conf-path= When no ?c is given
The path of the default nginx.conf under the option. If not specified, defaults to /conf/nginx.conf
–pid-path=
The path of the default Nginx.pid if no pid directive is specified in nginx.conf. If not specified, defaults to /logs/nginx.pid
wait
Nginx start, stop, smooth restart
Start Nginx
To start Nginx, you can execute the following command. Assuming that Nginx is installed in the /usr/locaUnginx/ directory, then the command to start Nginx is:
/usr/local/nginx/sbin/nginx -c
/usr/local/nginx/conf/nginx.conf
The parameter “-c” specifies the path of the configuration file. If the “-c” parameter is not added, Nginx will load the nginx.conf file in the conf subdirectory of its installation directory by default
Nginx stop
There are many ways to stop Nginx. Generally, Nginx is stopped by sending a system signal to the main process of Nginx.
We can use the ps command to find the main process number of Nginx:
ps ?ef | grep nginx
650) this.width=650;” src=”http://upload.server110.com/image/20130817/1441292095-0.png” />
As can be seen from the figure, the remark information of one Nginx process is “master
process”, which means it is the main process, and the other process has a note information of “worker
process”, indicating that they are child processes. 32244 is the main process number.
If the path where the pid file is stored is specified in the nginx.conf configuration file (for example: /usr/local/webserver/nginx/logs/nginx.pid;), the current main process number of Nginx is stored in this file. If the storage path of the pid file is not specified, the nginx.pid file is stored in the logs directory of the Nginx installation directory by default. Therefore, we can also directly use the following command to save the steps of finding the Nginx main process ID:
kill – signal type
`/usr/local/webserver/nginx/logs/nginx.pid`
(1) Stop Nginx calmly.
kill – QUIT Nginx main process number or kill
-QUIT
`/usr/local/webserver/nginx/logs/nginx.pid`
(2) Stop Nginx quickly
kill – TERM Nginx main process number or kill -TERM
`/usr/local/webserver/nginx/logs/nginx.pid`
kill – INT Nginx main process number or kill -INT
`/usr/local/webserver/nginx/logs/nginx.pid`
(3) Forcibly stop all Nginx processes
pkill ?9 nginx
Nginx Graceful Restart
If you change the configuration file of Nginx (nginx
conf), if you want to restart Nginx, you can also send a system signal to the Nginx main process. However, before restarting, confirm the Nginx configuration file (nginx.conf) is correct, otherwise Nginx will not load the new configuration file. You can judge whether the Nginx configuration file is correct by the following command:
/usr/local/webserver/nginx/sbin/nginx?t -c
/usr/local/webserver/nginx/conf/nginx.conf
If the configuration file is incorrect, the screen will prompt the error line of the configuration file:
[emerg]: unknown directive “abc” in
/usr/local/webserver/nginx/conf/nginx.conf:55
configuration file /usr/local/webserver/nginx/conf/nginx.conf
test failed
If the configuration file is correct, the screen will prompt the following two lines of information:
the configuration file
/usr/local/webserver/nginx/conf/nginx.conf syntax is OK
configuration file /usr/local/webserver/nginx/conf/nginx.conf
test is successful
At this point, you can restart Nginx smoothly.
kill -HUP Nginx main process number
kill-HUP
`/usr/local/webserver/nginx/logs/nginx.pid`
When Nginx receives a HUP signal, it tries to parse the configuration file first, and if successful, applies the new configuration file (for example, reopening log files or listening sockets). Afterwards, Nginx runs new worker processes and gracefully shuts down old ones. Tell the worker process to close the listening socket, but continue to serve currently connected clients. After all clients’ services are completed, the old worker processes are shut down. If the application of the new configuration file fails, Nginx will continue to work with the old configuration.
Nginx supports the following signal types:
TERM, INT close quickly;
·QUIT closes gracefully;
HUP restarts smoothly and reloads configuration files;
· USR1 reopens the log file, which is more useful when cutting the log;
· USR2 smooth upgrade executable program;
·WINCH calmly closes the working process.
Smooth upgrade of Nginx
When it is necessary to upgrade, add, or delete server modules in the running Nginx, the executable program of the old version can be replaced with the executable program of the new version and recompiled Nginx without interrupting the service. The steps are as follows:
(1) Use a new executable program to replace the old executable program. For compiled and installed Nginx, the new version can be compiled and installed into the old version of the Nginx installation path. Before replacing, you’d better make a backup of the old executable.
(2) Send the following command:
kill ?USR2 old version nginx main process number
(3) The main process of the old version of Nginx will rename its .pid file to .oldbin (for example: /usr/local/webserver/nginx/logs/nginx.pid.oldbin), and then execute the new version of the Nginx executable program , which in turn starts a new master process and a new worker process.
650) this.width=650;” src=”http://upload.server110.com/image/20130817/1441291517-1.png” />
(4) At this point, the new and old versions of Nginx instances will run simultaneously to jointly process incoming requests. To gradually stop an old Nginx instance, you must send the WINCH signal to the old master process, and its worker processes will then gracefully shut down:
kill -WINCH old version of Nginx main process number
(5) After a period of time, the old worker process (worker
process) exits after processing all connected requests, and only the new worker process handles incoming requests:
650) this.width=650;” src=”http://upload.server110.com/image/20130817/1441293N5-2.png” />
(6) At this time, we can decide whether to use the new version or restore to the old version:
kill ?HUP
Old master process number: Nginx will start its worker process without reloading the configuration file;
kill ?QUIT new main process number: calmly shut down its worker process (worker process);
kill ?TERM new main process number: force exit;
kill
New master process ID or old master process ID: If for some reason the new worker process cannot exit, send it a kill signal.
After the new main process exits, the old main process will remove the .oldbin prefix and revert to its .pid file. In this way, everything will be restored to before the upgrade. If the upgrade attempt is successful and you want to keep the new server, you can send the QUIT signal to the old master process to make it exit and leave only the new server running:
650) this.width=650;” src=”http://upload.server110.com/image/20130817/1441292120-3.png” />