最近经常碰到关于crontab不能执行的，初步总结了有以下几个原因：
第一，脚本的原因：大多数情况下，我们要相信科学，相信计算机，不是有鬼，就是我们的脚本的问题，这种问题导致crontab不能执行的概率占到70%以上。因为程序执行到某一步导致crontab终止执行，我就碰到一次在迁移代码的时候将数据库连错了。导致无法访问而死在那里了。
第二，执行环境问题，当我们碰到第一情况下，一般都可以通过手动执行程序将问题扼杀在摇篮里，一般情况下高手是不应该犯第一种错误的。问题是当我们手动执行成功而crontab不能执行的时候，笔者碰到一次就是执行环境的问题，例如相关路径的设置问题。解决方案：在代码最前面执行 source /home/user/.bash_profile
第三，系统时间不正确。这种问题最好理解，也是比较常见和隐蔽的问题，解决方案：date -s ********
第四，就是我们的脚本是否有可执行权限。必须保证执行脚本的用户有执行改文件的权限。
第五，crontab 守护进程死掉了。这种情况是极少发生的，但也不排除，当我们实在是找不到其他原因的时候可以用。解决方案：重启该进程。
另外，介绍大家一个关于如何查看crontab最修修改时间的方法：
进入目录/var/spool/cron/里面会有N个用户名为文件名的文件，只要建立过crontab的用户在这里都会有以该用户名为文件名的文件，该文件的最后修改时间就是该用户的的crontab的最后修改时间。
crontab 就是一个定时任务了。但有一些网友配置好crontab后发现第二天起来没有执行指定任务了，那么这个问题有权限，限制等等原因，我们来给各位总结一下关于crontab不执行的解决办法。
没有按照规范写以下的shell脚本导致执行失败通过CentOS中的定时任务执行shell脚本失败，进行排查：
1）手动执行shell脚本（sh backup.sh）成功执行，排除sh脚本的语法错误。
2）通过nano /etc/crontab命令查看定时任务，发现除过执行sh的定时任务外，其他任务都能正常执行。检查其代码，
发现对SHELL、PATH、MAILTO、HOME还没有好好了解过，以往都是注意下面的时间规则，所以查了一下定义：
1）SHELL，变量的值指定shell 环境（此处默认为 bash shell）；
2）PATH，变量定义用来执行命令的程序路径；
3）MAILTO，任务的输出被邮寄给 MAILTO 变量定义的用户名，如果变量被定义为空白字符串，电子邮件就不会被寄出；
4）HOME，变量可以用来设置在执行命令或脚本时使用的主目录；
随后看到SHELL的定义先用env一下看一下系统默认shell是哪个地址，
[root@AY data]# env
HOSTNAME=AY
TERM=xterm
SHELL=/bin/bash
…
随后打开shell脚本查看，果然没有对shell脚本配置地址。好了，找到了一个问题，下面就根据文档说明在shell脚本开始的地方打上该shell地址，如我的env是SHELL=/bin/bash，那么shell脚本开始就应该如下：
#!/bin/bash
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:~/bin
export PATH
添加完后重启服务service crond restart，检查脚本运行情况，顺利执行~
这次是按排除法检查了错误原因，主要还是由于没有按照规范写下的shell脚本导致执行失败。
下面再列出几个常见的没有按规范编写shell会出现的问题：
1）由于启动脚本用的是系统的crontab所以必须定义sh文件的目录以及具体日志的具体路径
2）注意使用加减法使用((num=$line+1))两个括号来进行弱类型转换
3）注意if判断大小于使用[[]]来进行，例如：if [[ $count > 0 ]],等于则可以使用一个[]即可
问题解决思路:
- 判断crontab是否有执行过,你可以添加一个每分钟执行的写文件的小脚本进行测试,如果有记录说明crontab本身服务没有问题.
如: Feb 7 14:45:01 1280859075761a8Z crond[13638]: (root) CMD (/backuptoqiniu/backuptoqiniu.sh )这里面应该是表示crontab已经成功执行了的,所以crontab服务没有问题. - 其实有经验多半就会知道crontab的执行是没有相关环境变量的,解决办法就是在脚本中打日志,另外默认将所有的命令采用全路径的方式.
调试方法:添加日志文件,将原来所有的echo 全部可以尝试追加到日志文件,或者在crontab写的时候追加日志.
45 14 * * * /backuptoqiniu/backuptoqiniu.sh >> /tmp/out.log 2>&1
ases.sql" -u $MYSQL_USER -h M Y S Q L S E R V E R − p MYSQL_SERVER -pMYSQLSERVER−pMYSQL_PASS D A T E B A S E > " DATEBASE > "DATEBASE>"NOW-Datab
我就没有看懂你这个是什么,是不是自己的命令不在默认的系统命令里面.
测试方法: 测试crontab的PATH与手动执行的PATH不一样.
可以在crontab的脚本里面添加个echo $PATH > /tmp/1.log
对比和你手动的终端下执行的echo $PATH
方法三，再看一个例子
crontab定时任务不执行的原因1、脚本语法错误在crontab脚本没有定时执行的时候，首先需要检查脚本的语法有没有出现问题。
2、环境变量问题有时我们创建了一个crontab，但是这个任务却无法自动执行，而手动执行这个任务却没有问题，这种情况一般是由于在crontab文件中没有配置环境变量引起的。我们在手动执行任务时是在当前shell环境下进行的，程序能够找到环境变量，而系统自动执行任务调度时，是不会加载任何环境变量的。因此，我们需要在shelll脚本中提供所有必要的路径和环境变量。
需要注意的主要有以下三点：
1）脚本中涉及文件路径时写全局路径；
2）脚本执行要用到java或其他环境变量时，通过source命令引入环境变量，如：
cat start_cbp.sh
#!/bin/sh
source /etc/profile
export RUN_CONF=/home/d139/conf/platform/cbp/cbp_jboss.conf
/usr/local/jboss-4.0.5/bin/run.sh -c mev &
3）当手动执行脚本OK，但是crontab死活不执行时。这时必须大胆怀疑是环境变量惹的祸，并可以尝试在crontab中直接引入环境变量解决问题。如：
0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh
3、系统任务调度及用户任务调度系统任务调度主要完成系统的一些维护操作，用户任务调度主要完成用户自定义的一些任务，可以将用户任务调度放到系统任务调度来完成（不建议这么做），但是反过来却不行，root用户的任务调度操作可以通过“crontab –uroot –e”来设置，也可以将调度任务直接写入/etc/crontab文件，需要注意的是，如果要定义一个定时重启系统的任务，就必须将任务放到/etc/crontab文件，即使在root用户下创建一个定时重启系统的任务也是无效的。
crontab定时任务不执行的解决办法
1、查看crontab执行记录如果出现了crontab定时任务不执行的情况，首先需要定位问题，那么就需要通过日志来确定问题所在。
crontab的日志位置一般位于/var/log/cron，利用下面的语句即可查看日志。
tail -f /var/log/cron
上面的/var/log/cron只会记录是否执行了某些计划的脚本，但是具体执行是否正确以及脚本执行过程中的一些信息linux会通过邮件形式发送到给该用户。
对于root用户该邮件记录位于/var/spool/mail/root，通过以下命令可以查看最近的crontab执行情况。
tail -f /var/spool/mail/root
mail邮件一般只会记录脚本执行成功与否，如果执行失败，无法给出进一步的错误信息，这时需要我们将语句执行的错误信息重定向至文件中，这样可以很方便的查看错误信息。下面就给出了一个简单的例子
0 6 * * * /root/script/ss.sh >> /root/for_crontab/mylog.log 2>&1
上述语句表示把错误输出和标准输出都输出到mylog.log中，在执行的时候会将命令执行的相关信息记录至mylog.log文件中。