排查思路是什么
计划任务没执行，按三步推进：确认任务是否被触发，看 cron 日志；确认命令本身是否执行失败，把输出重定向到文件抓现场；确认环境差异，cron 会话没有登录 shell，PATH、LANG 与工作目录都和手工执行不同。绝大多数手动能跑、计划任务不跑的情况，根因都在第三步。
基本信息
| 服务名 | RPM 系 crond；DEB 系 cron |
|---|---|
| 日志 | /var/log/cron、syslog；journalctl -u cron |
| 用户任务 | crontab -e -u <用户> |
| 系统任务 | /etc/crontab、/etc/cron.d/、cron.hourly 等目录 |
| 环境特点 | 无登录 shell，PATH 通常只有 /usr/bin 与 /bin |
典型使用场景
- 任务完全没触发，先确认服务在运行、语法是否被接受
- 任务触发了但报错，需要把输出重定向到日志抓原因
- 脚本依赖相对路径或自定义变量，手工能跑自动失败
- 任务执行时间超过调度间隔，上一轮未结束就重叠
- 偶发漏跑，主机负载高导致调度延迟
第一步确认是否触发
第一步确认是否触发
systemctl is-active crond # RPM 系，返回 active 才算在运行
journalctl -u crond -n 100 --no-pager | tail -30
grep CRON /var/log/cron 2>/dev/null | tail -20 # 任务被调度的记录
crontab -l # 核对本用户实际生效的条目
ls -l /etc/cron.d/ # 系统级任务目录与权限第二步最小验证与抓输出
第二步最小验证与抓输出
# 用最小任务先验证整条链路
* * * * * /bin/date >> /tmp/cron-debug.log 2>&1
# 真实脚本把标准输出与标准错误都落文件
0 2 * * * /bin/bash /opt/scripts/job.sh >> /var/log/job.log 2>&1
tail -f /var/log/job.log # 观察执行结果症状对照根因
| 症状 | 常见根因 | 处理 |
|---|---|---|
| 有调度记录但无输出 | 命令失败或输出被丢弃 | 加重定向后重跑并看日志 |
| 没有调度记录 | 服务未运行或语法被拒 | 启动服务并检查 crontab 语法 |
| 手工可跑自动失败 | PATH 或变量缺失 | 脚本内写绝对路径并显式导出变量 |
| 任务重叠执行 | 上一轮未结束 | 用 flock 加锁或错开时间 |
cron 的报错邮件需要本机有 MTA 才能发出，未装邮件服务时任务失败不会有人收到；生产上统一改成日志文件加监控告警，不依赖邮件通知。
任务频率别压得太密：分钟级任务若执行时间超过间隔就会重叠，用 flock 加锁或改用 systemd timer 的串行触发更稳。