排查nginx日志切割脚本归档丢失，核心是验证路径是否存在、是否可写、是否被正确引用；需逐项检查日志源路径、备份目录、pid文件路径的实际情况，结合set -x调试、usr1信号生效验证及logrotate冲突排查。
排查 Nginx 日志切割脚本因路径错误导致归档文件丢失，核心是“验证路径是否存在、是否可写、是否被正确引用”。这类故障通常不报错，而是静默失败——日志没切、旧文件持续增长、备份目录空空如也。
确认脚本中所有路径是否真实存在且权限正确
路径写错最常见于三类位置：日志源路径、备份目标路径、PID 文件路径。不能只看脚本里写了什么，要逐个用 ls -ld 和 stat 实际检查：
-
日志源路径（如
/usr/local/nginx/logs/access.log）：执行ls -l /usr/local/nginx/logs/access.log，确认文件存在且非空；若路径是软链接，用readlink -f展开真实路径 -
备份目录路径（如
/usr/local/nginx/logs/backup）：执行ls -ld /usr/local/nginx/logs/backup，确认目录存在、属主属组正确（如 nginx 用户需有写权限）、不是只读挂载 -
PID 文件路径（如
/usr/local/nginx/logs/nginx.pid）：先查 nginx 实际配置——nginx -t -q && nginx -V 2>&1 | grep "prefix\|pid"，再用cat或ps aux | grep nginx验证 PID 文件真实位置；常见错误是脚本硬写/var/run/nginx.pid，但实际在/usr/local/nginx/logs/nginx.pid
检查脚本执行时的工作目录和变量展开是否准确
Shell 脚本中路径拼接容易出错，尤其含变量时。别只看代码，要模拟执行过程：
- 在脚本开头加
set -x，再手动运行一次：bash -x /opt/cut_nginx_log.sh，观察每条命令实际执行的路径（比如mv /logs/access.log /logs/backup/access.log-20260729是否与预期一致） - 重点检查日期变量生成逻辑：
date -d "-1 day" "+%Y%m%d"在跨月/跨年时是否异常（如 7 月 1 日执行可能得 0630，而非预期的 0630）；建议改用date -d "yesterday" "+%Y%m%d"更可靠 - 路径中避免相对路径或未引号包裹的变量，例如
mv $log_path/access.log $log_path/backup/...若$log_path含空格会崩，应写作mv "$log_path/access.log" "$log_path/backup/..."
验证 USR1 信号是否真正发给了 Nginx 主进程
归档文件“丢失”，有时其实是日志没切走——因为 kill -USR1 没生效，Nginx 仍在往原文件写。这常因 PID 文件路径错或进程已死：
- 执行
kill -0 $(cat /path/to/nginx.pid) 2>/dev/null && echo "alive" || echo "dead"，确认进程存活且 PID 文件内容有效 - 手动触发一次切割后，立刻执行
ls -l /usr/local/nginx/logs/access.log*，看是否有新时间戳的文件生成；再tail -n 1 /usr/local/nginx/logs/access.log，对比时间戳是否更新——若仍写旧文件，说明 USR1 未成功重载句柄 - 检查 Nginx 错误日志（
error.log），搜索open() "/path/to/log" failed或permission denied，说明日志目录不可写，Nginx 自动降级为静默丢弃，不会报错到 stdout
回溯归档行为是否被 logrotate 干扰或覆盖
如果服务器同时启用了系统级 logrotate 或宝塔等面板的自动切割，脚本和外部轮转工具可能冲突，造成文件被重复移动或覆盖：
- 查
crontab -l和systemctl list-timers --all，确认没有其他定时任务也在操作同一日志路径 - 检查
/etc/logrotate.d/下是否有 nginx 相关配置，运行logrotate -d /etc/logrotate.d/nginx看调试输出是否匹配你的脚本逻辑 - 在备份目录中执行
ls -lti（带 inode），若发现多个同名归档文件 inode 相同，说明某处用了copytruncate，会导致数据丢失而非迁移
