Logrotate 日志切割不生效的主因是未被触发，需逐层排查：定时任务是否运行、配置是否加载、路径是否匹配、服务是否兼容。
Logrotate 日志切割不生效，最常见的情况是配置写对了、手动执行也成功，但日志却一直膨胀不轮转——这说明问题不在语法，而在“没被触发”。排查需按执行链路逐层验证：定时任务是否运行、配置是否加载、日志路径是否匹配、服务行为是否兼容。
确认 logrotate 是否真被定时任务调用
logrotate 本身不常驻，依赖外部调度。默认由 /etc/cron.daily/logrotate 脚本每天触发一次，新版 systemd 环境则通过 timer 单元管理。
- 检查定时器是否启用：systemctl list-timers | grep logrotate，应看到类似
logrotate.timer的活动条目 - 若无输出，说明 timer 未启用，可执行 sudo systemctl enable --now logrotate.timer
- 容器或精简系统可能压根没开 cron，需手动加 crond 或改用 logrotate -f 主动触发
- 查看最近执行记录：grep "logrotate" /var/log/syslog 或 journalctl -u cron | grep logrotate
验证配置文件是否被正确加载
logrotate 主配置 /etc/logrotate.conf 必须显式 include /etc/logrotate.d/ 目录，且你的规则文件必须放对位置、权限合规。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 运行 grep -r "include" /etc/logrotate.conf，确认存在
include /etc/logrotate.d（路径不能带星号或错写为logrotate.d/） - 检查你的规则文件是否在 /etc/logrotate.d/ 下：ls -l /etc/logrotate.d/ | grep yourapp，权限应为
-rw-r--r--（644） - 注意加载顺序：/etc/logrotate.d/ 下文件按字典序读取，若多个规则匹配同一路径，后加载的会覆盖前者
- 用 debug 模式看实际解析结果：sudo logrotate -d /etc/logrotate.conf | grep -A5 "your-log-path"
检查日志路径与轮转策略是否匹配
路径写错、通配符失效、策略冲突都会导致跳过轮转。尤其注意 size 和时间策略不可共存，以及应用直写日志带来的绕过风险。
- 确保日志文件真实存在且路径完全匹配（区分软链接与目标文件；若用软链，需加
copytruncate或copy） -
size 100M与daily不能同时出现，否则以时间策略为准，大小限制无效 - 若日志由 Go/Python 等程序直接写入 /var/log/app/app.log，它不走 syslog，logrotate 配置再准也没用——必须让应用自身支持重开句柄，或在
prerotate中通知其 reload - 查看轮转状态：cat /var/lib/logrotate.status | grep "your-log-file"，看最后处理时间是否更新
排除 copytruncate、missingok 等参数引发的静默失败
某些参数组合看似安全，实则掩盖问题。比如 missingok 遇到路径不存在时跳过创建，create 就不会执行，最终导致新日志无法写入。
- 生产环境慎用
missingok；更稳妥的是用notifempty+ 显式create 0644 user group，权限要匹配日志写入进程用户 -
copytruncate是关键：服务持续写日志时，它先复制再清空原文件，避免因文件句柄失效中断写入 - 若日志写入方不支持截断（如部分 Java 应用），需改用
prerotate发送信号（如kill -USR1）让其主动切日志 - 测试时优先用 logrotate -d -f，观察 debug 输出中是否有 “skipping”、“no matches”、“not rotated” 等提示
