关键是从文件创建、轮转执行、信号发送三环节统一用户身份和权限控制：确认nginx真实运行用户（如www-data），在logrotate配置中用create指定属主属组、su切换上下文、sharedscripts确保单次postrotate，再通过logrotate -f -v验证新日志创建与写入。
要让 Nginx 日志切割不因权限错乱而失败，关键不是只配 daily 或 rotate，而是从文件创建、轮转执行、信号发送三个环节统一用户身份和权限控制。logrotate 默认以 root 运行，但 Nginx 通常用 www-data 或 nginx 用户写日志——两者不一致就会导致新日志无法写入、旧日志残留、甚至服务报错。
确保新建日志文件权限与属主完全匹配
仅靠 create 0640 nginx nginx 不够稳健：如果系统中实际运行 Nginx 的用户是 www-data（如 Ubuntu/Debian），而配置里写成 nginx，logrotate 创建的文件属主错误，Nginx 就会因“Permission denied”写不进日志。
- 先确认真实运行用户：ps aux | grep nginx | grep -v grep，看 WORKER 进程的 USER 列
- 在 /etc/logrotate.d/nginx 中明确使用该用户：create 0640 www-data adm（adm 是常见日志组，兼容性比单独 nginx 组更好）
- 加上 su www-data adm，让整个轮转动作（包括 postrotate 脚本）都以该用户身份执行，避免 kill -USR1 因权限不足被拒绝
用 sharedscripts + su 避免多文件重复发信号或权限冲突
当配置路径为 /var/log/nginx/*.log 时，logrotate 默认对每个匹配文件单独执行 postrotate。若没加 sharedscripts，它可能对 access.log 和 error.log 各发一次 USR1，而第二次发信号时 PID 文件可能已失效，导致报错；更糟的是，若两次 postrotate 没统一用户上下文，其中一次可能失败。
- 必须添加 sharedscripts，确保所有日志文件处理完后，只执行一次 postrotate 块
- 配合 su www-data adm，保证 postrotate 中的 kill -USR1 由正确用户发起，不触发 SELinux/AppArmor 拦截
- 检查 PID 路径是否准确：/run/nginx.pid（systemd 系统常用）还是 /var/run/nginx.pid，并在脚本中加判断
验证配置是否真正生效，不止看文件名
很多配置看似正确，但一跑就出问题，是因为没验证底层行为。重点不是“有没有 .1.gz”，而是“Nginx 是否真在往新文件写”。
- 手动测试：logrotate -f -v /etc/logrotate.d/nginx，观察输出中是否有 creating new log file with mode = 0640 和 running postrotate script
- 检查新日志权限：ls -l /var/log/nginx/access.log，确认属主、属组、权限与 create 行完全一致
- 实时验证写入：tail -f /var/log/nginx/access.log，同时 curl 一个页面，看新请求是否立刻出现在该文件中（而不是 .1 或 .1.gz 里）
权限错乱不是配置写得不够多，而是用户、组、执行上下文三者没对齐。把 su、create、sharedscripts 三项配齐，再加一次带 -v 的强制执行验证，基本就能避开 90% 的权限类故障。
