In the previous article, after we have installed Nginx and configured the Nginx file, I need to operate the command line of Nginx at this time. This article mainly explains the related knowledge of Nginx command line and familiarizes ourselves with Nginx command line operation through the daily hot deployment and cutting log file scenarios.
Recommended reading: What does Nginx know?
Nginx command line
- Format: nginx -s stop
- Help: -? - h
- Use the specified profile: - c
- Specifies the configuration instruction: - g (to override the instruction in the configuration file)
- Specify run Directory: - p
- Send signal: - s (stop service immediately: stop, stop service gracefully: quit, reconfigure file: reload, restart logging file: reopen)
- Test the configuration file for syntax errors: - t -T
- Print version information and compilation information of nginx: - v -V
The nginx command is very similar to most Linux commands. It is nginx plus basic instructions, plus instruction related parameters. By default, nginx will look for the configuration file in the location specified when the configure command was executed, but you can specify the configuration file through - c, and you can specify the configuration instruction through - g.
Generally, the way for nginx to operate the running process is to send signals, which can be sent by linux general kill Command or nginx - s command.
Next, let's familiarize ourselves with Nginx's command-line operations with a few chestnuts.
Reload profile
By default, the configuration file is under the conf file of the installation directory. The file name is nginx.conf. We can open it to have a look:
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}If we need to enable gzip compression, we can remove the previous comments. After we modify the nginx configuration file, we can restart the nginx service through the command. / nginx -s reload of nginx.
Nginx hot deployment
When replacing the old version with the new version of nginx, if the deployment is not hot, you need to cancel the nginx service and restart the service to replace it successfully, which will disconnect the users you are visiting. Therefore, in order to upgrade the version without affecting the user's experience, you need to upgrade the version by hot deployment.
Next, let's have a hot deployment together.
Because the main purpose of upgrading is to replace binaries, the old binaries should be backed up before upgrading.
# Backing up legacy nginx binaries mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old
Then download the latest version of nginx, decompress it, compile it, and copy the compiled version of nginx binaries to the sbin directory under the installation directory.
# Download the latest version of nginx on the official website wget http://nginx.org/download/nginx-1.17.2.tar.gz # decompression tar -xzvf nginx-1.17.2.tar.gz cd nginx-1.17.2 ./configure --prefix=/usr/local/nginx # Compile make # Replace the old nginx executor cp -r /usr/local/nginx-1.16.1/objs/nginx /usr/local/nginx/sbin/ -f
Check the health of nginx through ps -ef | grep nginx:
[root@wupx sbin]# ps -ef | grep nginx root 1752 1 0 20:39 ? 00:00:00 nginx: master process ./sbin/nginx nobody 1783 1752 0 20:41 ? 00:00:00 nginx: worker process root 1787 1 0 20:41 ? 00:00:00 wget http://nginx.org/download/nginx-1.17.2.tar.gz root 4357 1708 0 21:00 pts/2 00:00:00 grep --color=auto nginx
You can see that the PID of nginx started at present is 1752. Next, you need to send a signal to the master process of nginx running to tell it that we are going to make a hot deployment.
# Send USR2 signal to the main process number of the old version to stop receiving requests from the old version of nginx and replace it with the new version of nginx kill -USR2 1752
Then check the health of nginx through ps -ef | grep nginx:
[root@wupx sbin]# ps -ef | grep nginx root 1752 1 0 20:39 ? 00:00:00 nginx: master process ./sbin/nginx nobody 1783 1752 0 20:41 ? 00:00:00 nginx: worker process root 1787 1 0 20:41 ? 00:00:00 wget http://nginx.org/download/nginx-1.17.2.tar.gz root 4391 1752 0 21:02 ? 00:00:00 nginx: master process ./sbin/nginx nobody 4392 4391 0 21:02 ? 00:00:00 nginx: worker process root 4394 1708 0 21:07 pts/2 00:00:00 grep --color=auto nginx
At this time, we need to send a signal to the old nginx, telling the old nginx to gracefully close all worker processes.
# Send the WINCH signal to the old main process, which will notify the old worker process to close gracefully, and then exit kill -WINCH 1752
To view the nginx status again:
[root@wupx sbin]# ps -ef | grep nginx root 1752 1 0 20:39 ? 00:00:00 nginx: master process ./sbin/nginx root 1787 1 0 20:41 ? 00:00:00 wget http://nginx.org/download/nginx-1.17.2.tar.gz root 4391 1752 0 21:02 ? 00:00:00 nginx: master process ./sbin/nginx nobody 4392 4391 0 21:02 ? 00:00:00 nginx: worker process root 4402 1708 0 21:08 pts/2 00:00:00 grep --color=auto nginx
It can also be found that the old nginx master process still exists. Its significance is: if there is a problem, it needs to be returned to the old version. We can send reload command to it to pull up the worker process again and turn off the new version. Keep it here for us to do version fallback.
To exit the reserved master process, you can use the kill -QUIT command:
# Send a QUIT signal to the old master process, which exits the reserved master process kill -QUIT 1752
After execution, 1752 process exits. You can see through netstat lntup that port 80 has been monitored by 4391 process (new version of nginx process).
So far, we have completed the hot deployment of nginx.
Log cut
In order to avoid the log file is too large and inconvenient to view, it is necessary to cut the log. First, back up the original logs:
# Back up the original log mv error.log old_error.log
View log size:
[root@wupx logs]# ll total 20 -rw-r--r-- 1 root root 6789 Nov 6 22:28 access.log -rw-r--r-- 1 root root 5 Nov 6 22:16 nginx.pid -rw-r--r-- 1 root root 7831 Nov 6 22:28 old_error.log
Next, log cutting:
# Log cut /usr/local/nginx/sbin/nginx -s reopen
View again:
[root@wupx logs]# ll total 24 -rw-r--r-- 1 nobody root 6789 Nov 6 22:28 access.log -rw-r--r-- 1 nobody root 60 Nov 6 22:30 error.log -rw-r--r-- 1 root root 5 Nov 6 22:16 nginx.pid -rw-r--r-- 1 root root 7831 Nov 6 22:28 old_error.log
After the above operations, we have finished the log cutting. The above operations are only to understand the operation process of log cutting, and it is not recommended to use it in direct production. It is recommended to write a shell script first and execute it regularly through the shell script.
Sample script:
#!/bin/bash
LOGS_PATH=/usr/local/nginx/logs/history
CUR_LOGS_PATH=/usr/local/nginx/logs
YESTERDAY=$(date -d "yesterday" +%Y-%m-%d)
mv ${CUR_LOGS_PATH}/access.log ${LOGS_PATH}/old_access_${YESTERDAY}.log
mv ${CUR_LOGS_PATH}/error.log ${LOGS_PATH}/old_error_${YESTERDAY}.log
## Send USR1 signal to NGINX main process. USR1 signal is to reopen the log file
kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)summary
This article mainly introduces the related knowledge of Nginx command line, overload configuration file, Nginx hot deployment, log cutting and other operations. It still needs more practical operations and practices to get real knowledge.
