logrotate 因权限问题报错时，需将配置文件设为644权限、日志目录设为755或更严格，并用-d调试验证；否则会跳过执行。
Logrotate 因属主或权限不匹配报错，常见于两类场景：配置文件本身权限不对，或日志所在目录权限太宽松。问题不是“不能运行”，而是 logrotate 主动拒绝执行以保障安全。
检查并修正 logrotate 配置文件权限
logrotate 要求配置文件（如 /etc/logrotate.d/myapp 或 /etc/logrotate.conf）权限必须是 0644 或 0444 —— 即仅所有者可写，组和其他用户只读。若为 664、600 或 755，会直接跳过该配置并报错：
- 用 ls -l /etc/logrotate.d/myapp 查看当前权限
- 若非 644，执行 sudo chmod 644 /etc/logrotate.d/myapp
- 注意：git 不记录读写权限变化，多人协作时容易因 umask 差异导致本地测试是 644，推送后变成 664；建议在 CI/CD 流程中加入权限校验步骤
修复日志父目录“insecure permissions”错误
当看到类似 error: skipping "/var/log/myapp/app.log" because parent directory has insecure permissions，说明日志所在目录（如 /var/log/myapp/）被设为组写或全局写（如 775、777、757）。logrotate 默认拒绝操作。
- 先查目录权限：ls -ld /var/log/myapp/
- 推荐设为 755（root:root）或更严格（如 750），避免组/其他用户有写权限
- 若服务需往该目录写日志，又不能改目录权限，可在配置中显式指定运行身份：
su root root（确保 logrotate 以 root 创建/重命名文件）
或 su myapp myapp（前提是 myapp 用户对目录有写权限）
验证是否真正生效
别急着 -f 强制执行，先用调试模式确认路径和权限都过关：
- 运行 sudo logrotate -d /etc/logrotate.d/myapp
- 观察输出中是否出现 “considering log …” 和 “rotating pattern” —— 有则说明已识别规则
- 若仍提示 “skipping” 或 “bad file mode”，说明配置文件或目录权限还没修好
- 调试通过后再加 -v -f 执行：sudo logrotate -vf /etc/logrotate.d/myapp
