cron 日志在哪里
cron 任务的执行痕迹记录在守护进程日志里，位置随发行版与日志系统而异：RHEL 系写在 /var/log/cron，Debian/Ubuntu 早期写在 /var/log/syslog，采用 systemd 的系统优先用 journalctl -u cron 或 -u crond 查询。要记住这条日志的能力边界：它只能回答「任务有没有被触发」，回答不了「业务有没有成功」——脚本的 stdout 与 stderr 不走守护日志。所以排查顺序是先用日志确认触发，再去脚本自己的日志与退出码里找结论。
基本信息
| 适用平台 | Linux（cronie 或 vixie-cron，配合 rsyslog 或 systemd-journald） |
|---|---|
| 日志位置 | RHEL 系 /var/log/cron；Debian 系 /var/log/syslog；systemd 系统用 journalctl -u |
| 服务名差异 | RHEL 系服务名是 crond，Debian 系是 cron |
| 关键字段 | 时间戳、CRON[pid]、执行用户名、CMD（实际执行的命令） |
| 权限说明 | 日志文件通常 root 可读，查询需要 sudo |
典型使用场景
- 确认任务是否按点触发，排除「任务根本没跑」的可能
- 核对实际执行的命令与 crontab 里写的是否一致
- 排查「改了 crontab 没生效」：看日志里是旧命令还是新命令
- 定位任务未执行的原因：cron 服务未启动、语法错误、用户被锁
- 与脚本自身日志对账，判断失败发生在调度层还是业务层
三系查法
三系查法
# RHEL/CentOS/Rocky
sudo grep CRON /var/log/cron | tail -n 20
# Debian/Ubuntu
sudo grep CRON /var/log/syslog | tail -n 20
# 通用（systemd 系统）
sudo journalctl -u crond --since today --no-pager | tail -n 30
sudo journalctl -u cron --since today --no-pager | tail -n 30
journalctl -u crond -f | grep -i session # 实时跟踪触发
sudo crontab -l -u deploy # 核对当前生效的配置日志字段读法
| 字段 | 含义 | 用途 |
|---|---|---|
| 时间戳 | 本次触发的时刻 | 与预期调度时间比对，确认是否按点执行 |
| CRON[pid] | 本次执行 fork 出的进程号 | 可与脚本日志中的 PID 对照，追同一次执行 |
| 用户名 | 以哪个用户身份执行 | 权限类问题的第一线索 |
| CMD | 实际执行的完整命令 | 核对是否与 crontab 一致，以及引号、PATH 的影响 |
日志只证明触发，不证明成功。脚本应自行记录开始时间、结束时间、退出码与关键输出，才能把「跑了」和「跑对了」分开判断。
Ubuntu 等未安装 rsyslog 的系统没有 syslog 文件，这不是日志丢失，直接用 journalctl -u cron 或按 --since 时间窗口过滤即可。