最有效的排查方式是直接看错误日志和手动测试；logrotate权限失败常静默跳过，需用-d参数调试，检查父目录权限、su配置、状态文件及cron执行记录。
直接看错误日志和手动测试是最有效的排查方式。logrotate 权限类失败通常不报错到系统日志，而是静默跳过或输出明确提示，关键在定位“它到底卡在哪一步”。
检查 logrotate 调试输出
运行带 -d（debug）参数的命令，能暴露真实原因：
- logrotate -d /etc/logrotate.d/your-app —— 查看是否因父目录权限被跳过，错误行会明确写 “skipping ... because parent directory has insecure permissions”
- 若提示 “error: unable to open ... Permission denied”，说明 logrotate 尝试创建/重命名文件时权限不足，问题出在目标路径的属主或目录写权限上
- 注意看调试输出末尾的 “rotating pattern” 部分：如果某条日志根本没出现在这里，说明配置未匹配到文件，可能路径写错、通配符失效或文件不存在
验证父目录权限是否触发安全限制
logrotate 对日志父目录有严格检查：不能 world-writable（777、707 等），也不能被非 root 组可写（除非该组是 root）。检查命令：
- ls -ld /var/log/your-app/ —— 看权限位和属主属组
- 常见“看似正常实则被拒”的情况：
• 目录权限为 775，属组是 appgroup（非 root）且该组有写权限
• 目录权限为 777 或含 sticky bit 但其他位开放（如 1777）
• 目录属主是普通用户（如 myapp），而 logrotate 默认以 root 运行，却没用 su 指令切换身份
确认 su 指令是否生效且匹配实际需求
加了 su 不代表就万事大吉，必须核对三件事：
- 配置中 su myuser mygroup 的用户和组必须真实存在，且该用户对日志文件有写权限（id myuser 查看）
- su 只影响轮转过程中的文件操作（重命名、create、postrotate 脚本等），不影响 logrotate 自身读取配置或判断触发条件
- 如果日志由非 root 进程持续写入（如 nginx - user nginx），且你用 su nginx nginx，那 create 行必须对应设置权限，例如：create 644 nginx nginx，否则新日志文件属主仍是 root，进程无法写入
观察状态文件与执行痕迹
logrotate 依赖状态记录来决定是否轮转，异常常藏在这里：
- 查看 /var/lib/logrotate/status，搜索你的日志路径，看最后轮转时间是否停滞或格式异常
- 对比 stat /var/log/your-app/app.log 和最近生成的归档文件（如 app.log.1）的修改时间、属主，判断轮转是否真正发生过
- 检查 cron 执行记录：grep logrotate /var/log/syslog | tail -10，确认定时任务是否真被触发，退出码是否为 0
