crontab未正常运行的原因及解析

简述

---

crontab的基本用法请参考Linux下定时任务crontab简介与使用。

crontab设置好后，脚本并没有执行？

crontab的执行情况与在终端直接运行脚本不一致？

使用crontab的同学可能会经常遇到这些问题，这天就以笔者经验为例来探讨一下crontab未正常运行的原因。

原因

---

crontab未正常运行的原因有多种，这里介绍一下调试方法。

一般情况下，按以下步骤调试即可找到原因。

1. 确认脚本无误

• 脚本具有当前用户的可执行权限
• 脚本在终端运行正常
• 脚本使用了诸如#!/bin/sh的良好规范

2. 确认cron服务正常

• ‘ps -ef | grep cron | grep -v grep’，确认cron服务正常
• 如果未启动，请启动 /sbin/service crond start

3. 检查环境变量

• cron是运行在一个非常苛刻的环境中的，与终端的环境并不一致
• 作为测试，可以使用* * * * * env > /tmp/env.output 输出cron的环境变量，与env对比
• 通常需要把PATH变量应用到cron中，如下方式可对所有脚本生效：

// crontab -e
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

也可以在编写脚本时指定（这是编写脚本的一个良好习惯）：

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

4. 某些版本的crontab可能需要在编辑时增加最后一行为空行

5. 写入crontab的脚本文件名中不能带点

• 这个规定很变态。你必须把backup.sh重命名为backup
• 好在这个问题很容易修复

6. 脚本不能被正常执行

• 如脚本中使用了scp、ssh等需要输入密码的操作
• 首先使用ssh-copy-id设置免密登录
• 然后再写脚本，注意文件要使用绝对路径

7. cron服务的时间与本地时间不一致

• 一般本地时间都会设置为UTC+8时区
• 但是cron服务的系统时钟仍然是UTC时区，这可以通过查看日志获得： tail -f /var/log/syslog
• 这种情况下，脚本会执行，但是会在设置的时间之后8小时才执行
• 这时如果确认时钟无误，就要重启cron服务： service cron restart

小结

---

曾经一个crontab共5分钟写完，调试却用了5个小时！

最后的结果只是因为脚本写了个相对路径，没有使用绝对路径。

不要放弃，分解问题，逐步完善，定能成功。