前言

crontab 写好了却到点不执行，是服务器运维最常见的坑之一。手动跑脚本正常，定时任务却没反应，问题往往不在脚本本身，而在服务状态、环境变量、时间格式和权限。本篇按从易到难的顺序列出排查点。

一、先确认crond服务在运行

systemctl status crond
# 没启动就启动并设开机自启
systemctl start crond
systemctl enable crond

服务没跑，所有定时任务都不会触发，这是第一个要查的。

二、检查定时任务格式是否正确

标准格式：分 时 日 月 周 命令

# 查看当前用户的定时任务
crontab -l
# 例如：每10分钟执行一次脚本
*/10 * * * * /usr/bin/php /www/backup.php

常见格式错误：分钟位置写成了小时、用了 * 却想表示"第1个"、命令路径用了相对路径。

三、查看cron日志，判断有没有触发

# CentOS7 日志位置
tail -f /var/log/cron

到点看日志里有没有出现这条任务：

• 日志里根本没有：格式没被识别、服务没跑、或时间写错；
• 日志有执行记录但没效果：是脚本/环境问题，往下查。

四、脚本环境变量问题（高频）

cron 的环境比手动登录干净得多，很多命令找不到、相对路径失败。解决：

1. 用绝对路径：脚本里和任务里都写全，比如 /usr/bin/php、/www/backup.php；
2. 开头加载环境：

   */10 * * * * source /etc/profile; /usr/bin/php /www/backup.php

3. 先手动用cron环境复现：env -i /bin/bash script.sh 模拟干净环境跑一遍。

五、权限与重定向

• 脚本要有执行权限：chmod +x /www/backup.sh；
• 脚本没加 shebang（#!/bin/bash）会找不到解释器；
• 把错误输出留下来方便定位：

  */10 * * * * /usr/bin/php /www/backup.php >> /www/log/cron.log 2>&1

  加了 2>&1，报错就写进日志，不再"静默失败"。

六、其他易漏点

1. 时区不一致：timedatectl 看系统时区，容器里时间错会导致任务错位；
2. 日和周同时指定是"或"关系，容易误触发，注意语义；
3. root和普通用户任务混淆：sudo crontab -l 看root的，普通用户看自己的；
4. 磁盘满了：日志写不进去，任务看似没执行。

总结

排查顺序：crond服务是否运行 → 任务格式对不对 → /var/log/cron 有没有触发 → 绝对路径和环境变量 → 执行权限与错误重定向 → 时区。手动正常、定时不跑，九成是环境变量和绝对路径问题。

遇到问题加QQ23979811 协助处理