共计 1631 个字符，预计需要花费 5 分钟才能阅读完成。
Nginx 是我们生产环境的主要入口，所有的请求都会在这里留下痕迹，所以会导致一个问题，它的日志文件会一天比一天的大。直到有一天你无法接受这个庞大的文件的时候，就你就会想到了切割文件的这个办法。
能想到切割日志的童鞋那肯定是对 Nginx 用的熟悉的不能再熟悉的了，所以这里我就不过多的阐述 Nginx 的应用了，只说一个点 -USR1 选项的用法
在没有执行 kill -USR1 `cat ${pid_path}` 之前，即便已经对文件执行了 mv 命令而改变了文件名称，nginx 还是会向新命名的文件”xxx.log_ 20130909”照常写入日志数据的。
原因在于：Linux 系统中，内核是根据文件描述符来找文件的
1、说说对 Linux 文件描述符的理解
文件描述符是 Linux 内核为每个打开的文件命名的一个整数标识。
Linux 内核为每一个进程生成 (或者说维护) 一个”文件描述符表”，这个文件描述符表记录的是“此进程所打开的文件(进行标识)”。
在这里的环境中，nginx 就是一个运行中的进程，这个进程早就打开了一个日志文件，在文件描述符表是记录了文件的。
即便日志文件的路径改变了，但是还是能够找到(根据文件描述符表可以定位)
2、说说脚本中 kill -USR $(cat /var/run/nginx.pid)语法的理解
当执行命令“kill -USR1 `cat ${pid_path}`”的时候，nginx.pid 文件中保存的其实就是一个数字(自己可以打开看一下，我这里是 894)，
nginx 将其主进程的 pid (进程号)写入到了 nginx.pid 文件中，所以可以通过 cat 命令直接拿到其主进程号, 直接操作指定的进程号。
kill -USR $(cat /var/run/nginx.pid)就等同于
kill –USR1 894 #指定发信号 (USR1) 信号给这个进程编号。
3、说说脚本中 kill -USR1 `cat ${pid_path}语法的理解
在 Linux 系统中，linux 是通过信号与”正在运行的进程”进行通信的。Linux 系统中，也很多预定义好的信号，像 SIGHUP。USR1 是用户自定义信号。
可以理解为：进程自己定义接到这个信号该干嘛(也就是进程编写者自己确定收到这个信号干嘛还是什么都不做都行，完全交给开发人员自己决定)。
而在 nginx 中，它自己编写了代码处理当我接到 USR1 信号的时候，让 nginx 重新打开日志文件。
具体理解如下：
1、nginx 的主进程收到 USR1 信号，会重新打开日志文件(以 nginx 配置文件中的日志名称命名, 就是配置文件中 access_log 项所设置的值，如果文件不存在，会自动创建一个新的文件 xxx.log)。
2、然后把日志文件的拥有者改为“工作进程(worker 进程)”，目的是让 worker 进程就具备了对日志文件的读写权限（master 和 worker 通常以不同用户运行，所以需要改变拥有者）。
3、nginx 主进程会关闭重名的日志文件(也就是刚才使用 mv 命令重命名成 xxx.log_ 20130909.log 的文件)，并通知工作进程使用新打开的日志文件(刚才主进程打开的文件 xxx.log)。
具体实现上更细化点就是，主进程把 USR1 信号发给 worker，worker 接到这个信号后，会重新打开日志文件(也就是配置文件中约定的 xxx.log)
#!/bin/bash
# 零点执行该脚本
#NGinx 日志文件所在目录
LOGS_PATH=/Disk/log/nginx
# 获取昨天时间 YYYY-MM-DD
YESTERDAY=$(date -d “yesterday” +%Y-%m-%d)
# 移动文件
mv ${LOGS_PATH}/access.log ${LOGS_PATH}/access_${YESTERDAY}.log
kill -USR1 $(cat /var/run/nginx.pid)
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-04/142802.htm
