logrotate不生成独立日志，其运行记录由rsyslog写入/var/log/syslog（Debian/Ubuntu）或/var/log/messages（RHEL/CentOS），状态则保存在/var/lib/logrotate/status中。
logrotate 运行日志不单独记录，要看 /var/log/syslog 或 /var/log/messages
logrotate 本身不写独立日志文件，它的执行过程会由系统日志服务（rsyslog）捕获并写入全局日志。所以查“最近一次运行”，本质是查系统日志里它被 cron 调用并完成的那条记录。
具体路径取决于发行版：
- Debian/Ubuntu 系统：主要看
/var/log/syslog - RHEL/CentOS 系统：主要看
/var/log/messages
命令示例（以 Ubuntu 为例）：
sudo grep "logrotate" /var/log/syslog | tail -n 5
你会看到类似这样的行：
Sep 7 06:25:01 myhost CRON[12345]: (root) CMD (test -x /usr/sbin/logrotate && /usr/sbin/logrotate /etc/logrotate.conf)
注意这个时间点只是 cron 触发的时间，不代表 logrotate 实际处理了哪些文件——那得结合 /var/lib/logrotate/status 判断。
/var/lib/logrotate/status 是真正的轮转时间依据
这个文件不是日志，而是 logrotate 的状态数据库，记录每个日志路径**上一次成功轮转的日期**。它决定了下次 logrotate 运行时是否满足 daily/weekly 条件。
直接查看：
sudo cat /var/lib/logrotate/status
输出类似：
"/var/log/myapp/app.log" 2026-9-7-06:25:01 "/var/log/nginx/access.log" 2026-9-7-06:25:02
关键点：
- 时间戳是 logrotate **内部认定的上次轮转时间**，不是系统调用时间
- 如果某条路径没出现在这个文件里，logrotate 会认为它“从未轮转过”，首次运行时就会强制处理
- 手动修改这个文件内容风险极高，可能导致轮转错乱或跳过归档
为什么 grep syslog 可能找不到 logrotate 记录
常见原因有三个，排查顺序建议从高到低：
-
/etc/logrotate.conf里启用了silent选项（极少见，但存在）——它会抑制所有日志输出 - rsyslog 配置中过滤掉了 cron 或 user-level 的 info 级别消息（检查
/etc/rsyslog.conf是否有~或stop规则匹配cron.*或user.*） - 日志轮转本身失败（比如权限不足、磁盘满），logrotate 没有输出成功信息，但错误可能被重定向或丢弃；此时应优先运行
logrotate -d /etc/logrotate.d/myapp查调试输出
想确认某次轮转是否真的生效，光看日志不够
系统日志只告诉你“cron 调用了 logrotate”，/var/lib/logrotate/status 只告诉你“它声称轮转了”，但最终是否生成了 .log-20260907、是否删掉了最老的归档、新日志是否被正确 create，必须手动验证：
- 检查目标目录下文件名变化：
ls -lt /var/log/myapp/*.log* - 确认新日志权限和属主是否符合
create 644 www-data www-data设置 - 用
lsof -p $(cat /var/run/myapp.pid) | grep log看进程是否已打开新日志文件（尤其 postrotate reload 后）
这三个动作比翻 syslog 更可靠——因为 logrotate 的“运行”和“成功”是两回事，而后者才是你真正要的结果。
