最近在与朋友梳理运维中遇到的坑的时候，发现大家都遇见过crontab计划任务没法正常执行的情况，如是简单的整理下,主要有如下几种情况：
1、环境变量是否定义
说明：crontab执行shell时，只能识别为数不多的环境变量，所有在脚本中最好使用export重新声明下该变量
说明：shell脚本rman备份oracle，直接执行脚本中的命令，可以备份，但写到脚本并放入crontab中，计划任务就无法执行（后来在脚本中source环境变量），再次执行就OK了
2、脚本是否有可执行权限
说明：对于shell脚本，如果没有可执行权限的话，最好能够使用/bin/sh 脚本绝对路径
3、crontab中无法执行php的解决方法
|
1
2
3
4
|
*
/5
* * * *
/usr/local/php/bin/php
/shells/cron/delete_redis
.php >
/dev/null
2>&1
检查发现，php并没有正常执行，可能是因为php中没配置绝对路径
解决方法：
*
/5
* * * *
cd
/var/www/cron
&&
/usr/local/php/bin/php
/shells/cron/delete_redis
.php >
/dev/null
2>&1
|
4、crontab下防止脚本运行冲突
CentOS6下（使用lockf或者flock）：
|
1
2
3
4
5
|
*
/10
* * * * （
/usr/bin/lockf
-s -t 0
/tmp/test
.lock
/usr/local/php/bin/php
test
.php >
/dev/null
2>&1）
lockf下参数说明：
-k: 一直等待获取文件锁
-s：不发出任何信息，即使拿不到文件锁
-t seconds：设定timeout超时时间是seconds秒，如果超过时间，则自动放弃
|
CentOS7下（使用flock）
|
1
2
3
4
5
6
7
8
9
10
11
12
|
*
/10
* * * * root flock -xn
/tmp/mytest
.lock -c
'cd /var/www/cron && /usr/local/php/bin/php /shells/cron/delete_redis.php'
>
/dev/null
2>&1
这样当任务未执行完成，下一任务判断到
/tmp/mytest
.lock被锁定，则结束当前的任务，下一周期再判断。
flock参数说明：
-s, --shared: 获得一个共享锁
-x, --exclusive: 获得一个独占锁
-u, --unlock: 移除一个锁，通常是不需要的，脚本执行完会自动丢弃锁
-n, --nonblock: 如果没有立即获得锁，直接失败而不是等待
-w, --timeout: 如果没有立即获得锁，等待指定时间
-o, --close: 在运行命令前关闭文件的描述符号。用于如果命令产生子进程时会不受锁的管控
-c, --
command
: 在shell中运行一个单独的命令
-h, --help 显示帮助
-V, --version: 显示版本
|
本文转自 冰冻vs西瓜 51CTO博客，原文链接：http://blog.51cto.com/molewan/1924382，如需转载请自行联系原作者
