Crontab任务为何不按预期运行

Crontab 任务跑偏了，没按预期执行？这事儿在运维日常里实在太常见了。别急着怀疑脚本写错，多数时候是几个小细节没照顾到。下面列出的排查步骤，基本能覆盖九成以上问题，你可以对照着一步步看看。

1. 先确认 cron 服务是不是活着。用 systemctl status cron（有的系统是 systemctl status crond）瞄一眼。如果状态不是 running，直接 systemctl start cron 启动它，这是最基础但最容易忽略的。

2. 再检查 cron 表达式有没有写错。五个字段分别代表分、时、日、月、星期，顺序不能乱。比如 * * * * * /path/to/script.sh 表示每分钟跑一次，看起来简单，但很容易误写成不期望的时间点。可以用在线工具验证一下。

3. 脚本本身要有可执行权限。很多任务不执行就是因为没加 chmod +x /path/to/script.sh，这步别忘了。

4. 路径问题是个大坑——在 cron 里必须用绝对路径，别指望相对路径。比如 /home/user/scripts/backup.sh 而不是 ./backup.sh，否则 cron 在有限的环境变量下根本找不到文件。

5. 日志是最好的老师。用 grep CRON /var/log/syslog 或者 journalctl -u cron 查看 cron 的输出，能直接看到任务是否被触发、错误信息是什么。遇到权限拒绝之类的提示，对症下药就行。

6. 环境变量是隐藏的杀手。cron 执行时继承的环境极其精简，很多系统命令或自定义路径会找不到。解决办法是在脚本头部写上 #!/bin/bash，然后在脚本里用绝对路径调用所有命令，或者提前声明 PATH 变量。

7. cron 会把任务的标准输出和错误通过本地邮件发给你。用 mail 命令查看，搞不好问题就写在邮件里。如果没配置邮件服务，可以重定向输出到日志文件自己看。

8. 任务执行时间太长，导致互相重叠或者超时？适当调整 cron 表达式的间隔，或者考虑用锁机制（比如 flock）避免并发冲突。

9. 系统时间和时区必须准确。用 timedatectl 检查，歪了的话任务会在你意想不到的时间点运行，别被“准点”的幻觉坑了。

如果上面这些全过了一遍还是不行，那多半是脚本内部逻辑或权限出了更刁钻的问题。仔细读一遍脚本，多打印几行调试日志，总能揪出来。