Preface
Nginx log splitting involves an instruction:
kill USR1 $(cat /usr/local/nginx/logs/nginx.pid)
According to some other blog information, the semaphore is USR1, which means reopening the file.
In the spirit of in-depth study, after in-depth understanding, the summary is as follows. If it is wrong, please correct it;
*********************************Gorgeous dividing line****************** ***************************
The above instructions include several knowledge points:
1.kill command
2. Signal amount
3.cat and $(): omitted
4.nginx.pid: omitted
********************************************************************************************
1.kill command
--It is a command in Linux system, the purpose is to terminate the specified program. You can see the explanation of kill in the document through man kill:
The command kill sends the specified signal to the specified process or process group. If no signal is specified, the TERM signal is sent. The TERM signal will kill processes which do not catch
this signal. For other processes, it may be necessary to use the KILL (9) signal, since this signal cannot be caught.
Most modern shells have a builtin kill function, with a usage rather similar to that of the command described here. The '-a' and '-p' options, and the possibility to specify processes by command
name are a local extension.
If sig is 0, then no signal is sent, but error checking is still performed.The meaning of the first sentence is: the kill command sends the specified signal to the specified process or process group (others are ignored for now), that is to say, Kill can terminate the process by sending a semaphore;.
Its format is as follows
Format: kill [-s signal|-p] [-q sigval] [-a] [--] pid
Option -s is explained as follows:
-s, --signal signal
Specify the signal to send. The signal may be given as a signal name or number.
(Send the specified semaphore, which can be a signal name or a number. Such as: (9) or HUP)
2. Signal amount
Semaphores are used to coordinate the communication between different processes for a certain shared resource or other operations. Due to space reasons, I won’t explain more. The following link is what I think is very good. Mark it:
https://blog.csdn.net/stt2836/article/details/88814282
Then, through knowledge point 1, we can infer that USR1 is a semaphore. After understanding it, we found that USR1 is a user-defined semaphore; that is, it can be defined by the required process. Since kill sends the semaphore to the nignx process, it should Defined in nginx code.
By reading the nginx code, you can see where it is defined:
In the file: core/ngx_config.h
#if (NGX_LINUXTHREADS)
#define NGX_REOPEN_SIGNAL INFO
#define NGX_CHANGEBIN_SIGNAL XCPU
#else
#define NGX_REOPEN_SIGNAL USR1
#define NGX_CHANGEBIN_SIGNAL USR2
#endifAccording to NGX_LINUXTHREADS, the meaning of the variable representing the semaphore is defined; the name of the variable NGX_REOPEN_SIGNAL can be translated as "reopened semaphore", what does it reopen?
Continue reading the code:
In ./os/unix/ngx_process.c
310 ngx_signal_handler(int signo)
//ngx_signal_handler函数为处理nginx信号量的函数,其中在case ngx_signal_value分支做出如下处理:
{
... ....
360 case ngx_signal_value(NGX_REOPEN_SIGNAL):
361 ngx_reopen = 1; //将该reopen状态打开,进程在看到这个变量是1的时候，就采取相应的操作;
362 action = ", reopening logs"; //定义动作类型为打开logs日志.为了方便后面写入日志;
363 break; //退出循环检测;
...
435 ngx_log_error(NGX_LOG_NOTICE, ngx_cycle->log, 0,
436 "signal %d (%s) received%s", signo, sig->signame, action);.
... ...
}When we send: kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid) command,
By looking at the error.log log, we can see:
2019/06/23 18:10:00 [notice] 6512#0: signal 10 (SIGUSR1) received, reopening logs
2019/06/23 18:10:00 [notice] 6512#0: reopening logs
2019/06/23 18:10:00 [notice] 10490#0: reopening logs
- Note: If you want to see this information, you need to adjust the errorlog level to [notice] in the nginx.conf configuration file, and then restart the service.
- Note 2: If you want to view more debug information, you need to configure the module: ./configure --with-debug (you can view the modules supported by nginx)
As follows:
worker_processes 1;
error_log logs/error.log notice;
events {
worker_connections 1024;
}In fact, at this point, you can know that the semaphore of USR1 is to tell the nginx process to reopen the log file;
But considering, doesn’t Kill terminate the process? Then how does nginx reopen the log file? What will happen to the nginx process after opening it? Continue to follow the code;
The process is detected by cyclically calling the ngx_master_process_cycle (process entry) function. This function is called when nginx is initialized and passed the command:
for ( ;; ) {...}重复调用;
263 if (ngx_reopen) { //如果ngx_reopen为真(1)
264 ngx_reopen = 0; ///将设置ngx_reopen为假;状态标识符.
265 ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reopening logs");//写入error-log日志中,
266 ngx_reopen_files(cycle, ccf->user); //新建log文件;
267 ngx_signal_worker_processes(cycle,
268 ngx_signal_value(NGX_REOPEN_SIGNAL));
269 }Note: NGX_LOG_NOTICE represents the level of the log; cycle is a structure that records important variables, cycle->log is the file identifier, and Linux operates files through file identifiers. This is why when doing segmentation, after modifying the name The process needs to be killed, otherwise even if the name is changed, nginx will still write to the file with the changed name based on the identifier;
The process calls the function: ngx_reopen_files to create a new log file and modify permissions and other operations:
1081 ngx_reopen_files(ngx_cycle_t *cycle, ngx_uid_t user)
1082 {
... ...
1110 fd = ngx_open_file(file[i].name.data, NGX_FILE_APPEND, //创建文件fd为文件描述流
1111 NGX_FILE_CREATE_OR_OPEN, NGX_FILE_DEFAULT_ACCESS);
....... //创建失败的操作.写入log
1123 #if !(NGX_WIN32) //判断平台;修改权限等操作
... ...
1143 if (fi.st_uid != user) { //修改所有者
1144 if (chown((const char *) file[i].name.data, user, -1) == -1) {
...
1157 }
1158
... ...
1163 if (chmod((const char *) file[i].name.data, fi.st_mode) == -1) { //修改权限
1164 ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
1165 "chmod() \"%s\" failed", file[i].name.data);
1174 }
1175 }
1176 }
1203 }
1204 The function of the ngx_open_file function is to open the file, and if the file does not exist, create a new file; (not important, just follow it up as a habit, you don’t need to read it)
#define ngx_open_file(name, mode, create, access) \
open((const char *) name, mode|create|O_BINARY, access)
#else
#define ngx_open_file(name, mode, create, access) \
open((const char *) name, mode|create, access)
#endifAfter the ngx_reopen_files function is executed, the ngx_signal_worker_processes function is called for process management: kill the old process and create a new process;
535 if (kill(ngx_processes[i].pid, signo) == -1) { //如果终止进程失败,写入日志
... ...
547 }
548 So far, the summary is as follows:
- 1. In the kill command, .9 is also a semaphore, which means to forcefully terminate the process. Sending other semaphores can communicate with the process (how to die through communication...)
- 2. The USR1 semaphore is defined by nginx to reopen the log; when the kill command sends USR1, nginx will reopen the log file and re-create the process;
- (Write a new suicide note before dying......)
Note: I always thought that the nginx process would not die after sending USR1, but it would only perform operations on the log file...I will understand after sorting it out.
Reposted from
https://blog.csdn.net/xinfuxuan4/article/details/93386815