error_log不记录轮转过程，仅反映轮转后nginx写入新日志的异常：如permission denied（权限错误）、no such file（路径缺失）或too many open files（文件描述符耗尽）；验证轮转生效需检查access.log是否清零、access.log.1是否生成、curl测试后access.log是否有新条目，以及error_log末尾有无上述三类报错。
error_log 本身不记录日志轮转的执行过程或状态，它不是轮转“控制器”，而是错误“记录者”。轮转由外部工具（如 logrotate）完成，Nginx 仅在收到 USR1 信号后重新打开日志文件。因此，想通过 error_log 监控轮转是否成功，关键不是找“轮转中”这类日志，而是看轮转后 Nginx 是否能正常写入新日志、有无权限/路径类错误。
轮转后必须检查的三类 error_log 异常
logrotate 执行完毕后，Nginx 主进程会 reload 日志文件句柄。若失败，error_log 里会出现明确报错：
- open() "/var/log/nginx/access.log" failed (13: Permission denied)：轮转后新日志文件权限不对（比如属主不是 www-data），Nginx 写不进去
- open() "/var/log/nginx/error.log" failed (2: No such file or directory)：logrotate 配置了 create，但路径不存在或父目录无写权限
- failed to open error log file: open() "/var/log/nginx/error.log" failed (24: Too many open files)：极少见，但说明系统文件描述符耗尽，连错误日志都打不开——轮转虽成功，服务已濒临崩溃
如何确认轮转已生效且 Nginx 正常接管
不能只看 logrotate 命令是否返回 0，要验证 Nginx 行为：
- 执行 sudo logrotate -f /etc/logrotate.d/nginx 后，立刻运行 ls -lh /var/log/nginx/*.log*，确认 access.log 变为 0 字节、access.log.1 或 access.log.1.gz 已生成
- 立刻发一个测试请求：curl -I http://localhost，再查 tail -n 1 /var/log/nginx/access.log —— 若有新条目，说明 Nginx 已写入新日志；若仍是空，说明轮转后日志未接管成功
- 检查 error_log 最后几行：tail -n 5 /var/log/nginx/error.log，确认没有上述三类权限/路径错误
用 error_log 辅助诊断轮转静默失败
某些轮转问题不会立刻报错，但会导致后续日志丢失。这时 error_log 的“沉默”反而是一种信号：
- 如果发现 error_log 文件时间戳停留在几天前，而 access.log 却持续增长，大概率是轮转脚本没跑、或 postrotate 中 kill -USR1 失败（比如 PID 文件路径错、Nginx 以非标准用户启动）
- 启用临时高日志级别辅助排查：error_log /var/log/nginx/error.log notice; 并重载，然后手动触发轮转。若看到 reopening logs 日志，说明 USR1 成功；若无此行，说明信号未送达
