cron 大多不留专门日志
cron 任务本身通常不写业务日志，只有任务自己在输出里留痕才会被发现。要确定一个计划任务有没有跑、什么时候跑的，得用三处信息交叉：计划定义（时间字段决定了理论触发时刻）、任务产物的文件时间（输出文件、日志、临时目录），以及系统日志里 cron 守护进程的记录。
发行版差异
RHEL 系把 cron 的执行记录写在 /var/log/cron，Debian/Ubuntu 系写在 /var/log/syslog 里并带 CRON 标记；容器化环境里 cron 可能根本没有守护进程记录，只能靠产物时间与任务定义推断。
基本信息
| 适用平台 | Linux（cron、anacron）、部分 busybox 精简系统 |
|---|---|
| 计划定义 | /etc/crontab、/etc/cron.d/*、/var/spool/cron/crontabs/*、crontab -l |
| 执行记录 | RHEL 系 /var/log/cron；Debian 系 /var/log/syslog 中的 CRON |
| 旁证 | 任务输出文件的 mtime、临时目录、数据库里的执行记录 |
| 时间字段 | 分 时 日 月 周，特殊值 @reboot、@daily 等 |
典型使用场景
- 发现可疑定时外联脚本：先用任务定义推算时刻，再用产物时间验证
- 用户 crontab 的 mtime 落在窗口内：结合 auth 日志定位是谁在何时写入
- 任务声称「每小时跑」但产物缺几个时段：判断是否被暂停或执行失败
- 排查软链接或符号命令被替换：核对 crontab 引用的脚本路径与文件时间
- 容器环境确认计划任务来源：容器内 crontab 与宿主机 cron 要分开查
三处交叉核对
三处交叉核对
# 系统级与用户级计划定义，注意所有用户都要看
grep -v '^#' /etc/crontab | tail -5
ls -l /etc/cron.d/ /var/spool/cron/crontabs/ 2>/dev/null
for u in root www-data; do echo "== $u"; crontab -l -u $u 2>/dev/null | tail -5; done
# 执行记录：发行版不同，路径不同
grep -i cron /var/log/cron 2>/dev/null | tail -10
grep -i cron /var/log/syslog 2>/dev/null | tail -10
# 用产物时间反推触发时刻
find /tmp /var/tmp -xdev -newermt '2026-01-02 00:00' -type f 2>/dev/null | head交叉来源与可信度
| 来源 | 能证明什么 | 局限 |
|---|---|---|
| 任务定义 | 理论上应当在何时触发 | 不证明实际执行过 |
| cron 守护进程日志 | 任务确实被调度并启动 | 并非所有发行版与容器都有 |
| 产物文件 mtime | 任务确实产生了输出 | mtime 可能被复制或改写 |
| 账号与网络日志 | 任务运行时的登录与外联动作 | 需要时间对齐后关联 |
@reboot 类任务没有固定时刻，只能结合系统启动时间（journalctl 的 boot 记录或 uptime）确定触发点。
用户的 crontab 文件本身也有 mtime，改动时刻与被植入时刻接近；它属于高价值时间戳，分析前不要用会改写时间的工具打开。