logrotate 通过读取 /etc/logrotate.conf 及其 include 的 /etc/logrotate.d/* 文件加载规则，实际生效任务需结合 logrotate -d 输出、/var/lib/logrotate.status 状态记录和 cron 调度验证。
查 logrotate 主配置和包含的全部规则文件
系统不会把所有轮转任务“注册”成一个清单供你一键查看，它靠读取配置文件来决定执行哪些任务。所以真正有效的做法是把 /etc/logrotate.conf 和它 include 的所有子配置都翻一遍。
最直接的方式是：
- 先看主配置：
cat /etc/logrotate.conf，重点找以include开头的行（比如include /etc/logrotate.d） - 再列出对应目录下的所有文件：
ls /etc/logrotate.d/ - 逐个检查这些文件内容，比如
cat /etc/logrotate.d/nginx、cat /etc/logrotate.d/syslog
注意：有些发行版（如 RHEL/CentOS）可能在 /etc/logrotate.d/ 下有大量服务专属配置；而 Debian/Ubuntu 则更倾向把规则直接写进主配置或少量大文件里。不要只扫一眼目录就以为“没几个”，实际可能有二三十个。
用 logrotate -d 模拟执行并观察加载了哪些文件
logrotate -d 不会真正轮转，但会完整解析所有配置，并把“本该处理哪些日志”打印出来——这是判断当前生效任务最可靠的依据。
执行命令：
logrotate -d /etc/logrotate.conf
输出末尾会出现类似这样的行：
reading config file /etc/logrotate.conf including /etc/logrotate.d/nginx including /etc/logrotate.d/rsyslog including /etc/logrotate.d/apt ...
这些 including 行就是当前系统实际识别到的所有轮转任务来源。只要出现在这里，就说明它会被 cron 定期触发。
常见陷阱：
- 某个配置文件语法错误（比如少了个
}），logrotate -d会直接报错并停止解析后续文件——你以为漏了任务，其实是某处配崩了 - 某些文件权限不对（比如非 root 可读），
logrotate会跳过，但-d默认不提示，得加-v才能看到“skipping”信息
确认 cron 是否真在调度这些任务
即使配置全对，如果 cron 没跑 logrotate，那些任务也等于不存在。
检查标准调度位置：
- Debian/Ubuntu：
cat /etc/cron.daily/logrotate（通常是个 shell 脚本，调用logrotate /etc/logrotate.conf） - RHEL/CentOS：
ls /etc/cron.daily/ | grep logrotate，或检查systemctl list-timers | grep logrotate
验证最近一次执行是否成功：
grep logrotate /var/log/syslog | tail -5
或直接看状态文件记录的时间：
cat /var/lib/logrotate.status | head -10
里面每行格式是 "/var/log/syslog" 2026-9-7-14:32:01，说明这个路径的日志上次轮转发生在那天那个时间点。没有出现的路径，基本可以判定没被纳入调度。
为什么 logrotate -f 不适合用来“发现”任务
很多人会试 logrotate -f /etc/logrotate.conf，以为能“触发所有任务并看到效果”。但这样做风险高、干扰大：
- 它会强制轮转所有匹配的日志，包括
/var/log/messages这类关键系统日志，可能打断正在排查的问题 - 如果某个服务（如 nginx）配置了
postrotate systemctl reload nginx，强制执行会真实重启服务，影响线上 - 它不告诉你“哪些没跑”，只报错已失败的；而
-d模式才暴露完整加载链路
真正要“发现”任务，别碰 -f。盯住 -d 输出 + 状态文件 + cron 调度路径这三块，缺一不可。尤其要注意 /etc/logrotate.d/ 下那些名字不起眼的小文件——比如 apt、unattended-upgrades，它们默默轮转着你根本想不到的日志。
