Nginx日志切割脚本在CentOS 7上的范本-LINUX-PHP中文网

logrotate是centos 7最稳妥的日志切割方案，自带无需安装，通过/etc/logrotate.d/nginx配置可实现每日轮转、30天保留、自动压缩与usr1平滑重启，配合missingok、notifempty等机制规避常见失败。

nginx日志切割脚本在centos 7上的范本

直接用 logrotate 配置最稳妥

CentOS 7 自带 logrotate，不需额外写脚本、不依赖 crontab 手动管理，也不用担心换行符或权限问题。手动 shell 脚本容易在 kill -USR1 时因 pid 文件路径错、权限不足、日志路径不存在而静默失败，而 logrotate 有 missingok、notifempty、sharedscripts 等兜底机制。

新建配置文件：/etc/logrotate.d/nginx，内容如下：

/var/log/nginx/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0644 nginx nginx
    sharedscripts
    postrotate
        if [ -f /run/nginx.pid ]; then
            kill -USR1 $(cat /run/nginx.pid)
        fi
    endscript
    dateext
    dateformat -%Y%m%d
}

注意几个关键点：

/run/nginx.pid 是 CentOS 7 默认 pid 路径；若你编译安装且改过 pid 路径（如 /usr/local/nginx/logs/nginx.pid），必须同步更新 postrotate 中的路径
create 0644 nginx nginx 确保新日志文件权限正确，否则 worker 进程可能无法写入
dateformat -%Y%m%d 必须紧接在 dateext 后，且只支持 %Y、%m、%d、%s 四个参数，%s 不推荐——秒级时间戳会导致同天多次切割时覆盖

手写 shell 脚本必须检查的三处硬伤

如果坚持用自定义脚本（比如要按小时切、或需额外归档逻辑），以下三点不验证就跑，90% 情况下会切不动或切完 nginx 不写新日志：

nginx.pid 文件是否可读：执行 cat /run/nginx.pid 看是否报 “No such file” 或 “Permission denied”。常见于非 systemd 启动、或 pid 路径被改但没同步到脚本中
日志路径是否真实存在且可写：运行 ls -l /var/log/nginx/，确认 access.log 和 error.log 存在，且属主是 nginx 或至少对 nginx 用户可写
脚本换行符是否为 LF：Windows 编辑后上传的脚本常含 $'\r'，导致 #!/bin/bash^M: bad interpreter 错误。用 file logs.sh 查看，若显示 “CRLF”，则运行 dos2unix logs.sh

一个最小可用范本（存为 /root/cut_nginx_log.sh）：

#!/bin/bash
LOG_DIR="/var/log/nginx"
PID_FILE="/run/nginx.pid"
DATE=$(date -d yesterday +%Y%m%d)
<p>[ -f "$PID_FILE" ] || { echo "PID file missing"; exit 1; }
[ -w "$LOG_DIR" ] || { echo "Log dir not writable"; exit 1; }</p><p>mv "$LOG_DIR/access.log" "$LOG<em>DIR/access</em>$DATE.log" 2>/dev/null
mv "$LOG_DIR/error.log" "$LOG<em>DIR/error</em>$DATE.log" 2>/dev/null</p><p>kill -USR1 $(cat "$PID_FILE") 2>/dev/null</p>

crontab 定时任务怎么写才不踩坑

定时任务不是写完就完事。CentOS 7 的 crond 默认以 root 身份运行，但环境变量和当前工作目录与交互式 shell 不同，容易导致脚本中命令找不到或路径解析失败。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

正确写法（运行 crontab -e 添加）：

0 0 * * * /bin/bash /root/cut_nginx_log.sh > /var/log/nginx/cut.log 2>&1

必须显式调用 /bin/bash，不能只写 /root/cut_nginx_log.sh；重定向输出到日志便于排查；时间设为 0 0 * * *（每天 0 点），避免用 */1 这类高频策略——Nginx 日志轮转本身不支持并发触发，重复 kill -USR1 可能导致日志丢失。

验证 cron 是否生效：

检查 cron 服务状态：systemctl status crond
查看 cron 日志：journalctl -u crond -n 20
临时改成每分钟执行一次测试，确认脚本能跑通后再改回每日

为什么 access.log 切完还是空？

这是最常被忽略的现象：脚本执行成功、kill -USR1 无报错、新文件生成了，但第二天发现 access.log 仍是空的。

根本原因只有两个：

Nginx 主进程没收到信号：检查 ps aux | grep nginx，确认 master 进程 PID 和 cat /run/nginx.pid 一致；若不一致，说明 nginx 是用其他方式（如 service nginx start 以外的方式）启动的，pid 文件未更新
worker 进程仍持有旧文件句柄：Linux 下 mv 不影响已打开的 fd，但 kill -USR1 后 worker 应自动 reopen 新日志。若没发生，大概率是 SELinux 阻断了 reopen 操作，临时关闭验证：setenforce 0；长期方案是加 SELinux 策略或用 copytruncate（但会丢日志）

真正可靠的判断方式，不是看 access.log 是否为空，而是看它最后修改时间是否在 kill -USR1 之后、且有新内容写入。用 tail -f /var/log/nginx/access.log 触发一次请求，立刻能看到实时追加。