logrotate -d 仅做配置解析和预演，不执行实际轮转；需加 -f 指定配置文件路径才能强制执行，-v 查看详细动作，postrotate 需手动验证是否成功运行。
logrotate -d 能看到配置是否被识别，但不执行轮转
用 logrotate -d 只是做 dry-run：它会读取配置、解析通配符、检查文件存在性、打印将要执行的动作，但跳过所有实际的 rename / compress / rotate 操作。这是最安全的第一步，能快速暴露语法错误、路径不存在、权限不足等问题。
常见错误现象包括：error: error accessing /var/log/myapp/*.log: No such file or directory（日志路径写错或目录为空），或 error: skipping "/var/log/myapp/app.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root")（父目录权限太松）。
- 务必加
-f（force）才强制触发轮转，否则即使满足时间/大小条件也不会真跑 -
-d不校验 postrotate 脚本语法是否合法，只看能否找到该脚本文件 - 如果配置里用了
include，-d会递归加载并报告所有包含的文件——这是排查“为什么我的规则没生效”的关键线索
logrotate -f 强制执行时必须指定配置文件路径
直接运行 logrotate -f 会报错：error: no config file specified。logrotate 不会自动 fallback 到 /etc/logrotate.conf，除非你显式传入。
正确做法是：
- 测试全局配置：
logrotate -f /etc/logrotate.conf - 测试单个应用配置（推荐）：
logrotate -f /etc/logrotate.d/myapp（注意：这个文件必须是独立有效的 logrotate 配置片段，不能依赖include外部定义的 shared 设置） - 加
-v查看详细动作：logrotate -fv /etc/logrotate.d/myapp，你会看到类似rotating pattern: /var/log/myapp/app.log forced from command line (7 rotations)的输出
注意：-f 不绕过 daily/weekly 等时间判断——它只是忽略“上次轮转时间是否已到”，但仍会检查文件是否存在、是否可读写、是否满足 size 条件等。
手动触发后如何验证 postrotate 是否真的运行了
很多人以为 logrotate -fv 输出了 running postrotate script 就万事大吉，其实不然。postrotate 脚本在子 shell 中执行，它的 exit code 不影响主流程，失败也不会中断轮转。
验证要点：
- 在 postrotate 脚本开头加日志：
echo "$(date): postrotate started" >> /var/log/myapp/rotate.log - 确保脚本末尾有
exit 0（否则某些版本 logrotate 会认为脚本失败并跳过后续操作） - 检查信号是否发给正确进程：
postrotate里用kill -USR1 $(cat /var/run/myapp.pid 2>/dev/null)前，先确认/var/run/myapp.pid存在且内容是数字 PID - 如果用
systemctl reload myapp，注意非 root 用户运行的 logrotate 可能无权执行该命令——建议改用systemctl --user reload myapp或提前配置 sudo 免密
测试环境与生产环境权限/SELinux 差异常被忽略
在本地 VM 或容器里测试通过的配置，上线后可能卡在 error: skipping ... because parent directory has insecure permissions 或 error: unable to open /var/log/myapp/app.log for compression。
根本原因通常是：
- 测试时用 root 手动跑，而 cron 里的 logrotate 是由 logrotate 组或特定用户启动，对目标目录缺少 r/w/x 权限
- SELinux 启用时，
logrotate进程默认域不允许写某些上下文的文件（如container_file_t），需用audit2why查日志，再用semanage fcontext修复 - 使用
copytruncate时，若应用本身以 O_APPEND 方式打开日志，截断后可能继续往旧 inode 写——这不会报错，但导致日志“丢失”，必须配合应用重开文件句柄（即靠 postrotate reload）
真正可靠的测试，得在跟生产一致的用户身份、SELinux 状态、文件上下文环境下跑一次 logrotate -fv，并立刻检查目标日志文件、归档文件、postrotate 日志三者的状态。
