最近在与朋友梳理运维中遇到的坑的时候,发现大家都遇见过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,如需转载请自行联系原作者