logrotate -f 需指定准确配置路径，否则无效；应先用 -d 调试验证执行计划，常见失败原因包括路径错误、权限不足、日志为空、文件被占用及服务未重载日志。
直接用 logrotate -f 加上正确的配置文件路径就能强制执行一次，但很多人输完命令没反应，问题几乎都出在“路径写错了”或“配置本身被跳过”。
必须指定准确的配置文件路径
logrotate 不会自动扫描所有规则，-f 后面必须跟一个它能读取并解析的配置文件：
- 只轮转 Nginx 日志：sudo logrotate -f /etc/logrotate.d/nginx
- 只轮转自定义服务（如 myapp）：sudo logrotate -f /etc/logrotate.d/myapp
- 想覆盖全局 + 所有子配置：sudo logrotate -f /etc/logrotate.conf，但前提是该文件里 include /etc/logrotate.d 这一行未被注释，且 /etc/logrotate.d/ 下所有配置语法合法
先用 -d 调试，别盲目 -f
logrotate -d 不改任何文件，只打印完整执行计划，是验证是否真能跑通的最可靠方式：
- 运行 sudo logrotate -d /etc/logrotate.d/myapp，看输出里有没有 “log does not need rotating” —— 有就说明当前不满足触发条件（比如配置了 daily 但今天已轮过，或 size +10M 但文件才 2MB）
- 如果报错 error: skipping "... because parent directory has insecure permissions，说明日志目录权限太松（如 777），logrotate 主动拒绝操作
- 输出中会明确列出：要重命名哪些文件、是否调用 postrotate、是否启用压缩、是否创建新文件等
常见“执行了却没效果”的原因
不是命令失效，而是配置或环境卡住了：
- notifempty 开启时，日志为空就跳过轮转 —— 先往文件里写点内容测试：echo "test" >> /var/log/myapp/app.log
- create 指令要求 logrotate 有权限在日志目录下新建文件 —— 如果目录属主是 myapp，而 logrotate 以 root 运行通常没问题；但如果配置里写了 su myapp myapp，而 myapp 用户无权写入该目录，就会失败
- 日志文件被进程独占打开（如 tail -f 或应用未释放 fd） —— 加上 copytruncate 可绕过重命名失败，让原文件被清空、应用继续写入，避免静默跳过
轮转后应用还在往旧文件写？重点查这两项
很多服务（Nginx、Java daemon 等）不会自动感知日志被重命名，导致新日志仍写进 app.log.1：
- 加 copytruncate：最轻量解法，先复制内容再清空原文件，应用无需 reload，但有极小概率丢失最后几行写入
- 配 postrotate 脚本：例如 nginx 需要 kill -USR1 或 systemctl reload nginx，确保它重新打开 app.log；注意脚本末尾加 endscript
