|
* * * * * command to be executed
- - - - - | | | | | | | | | +----- day of week (0 - 6) (Sunday=0) | | | +------- month (1 - 12) | | +--------- day of month (1 - 31) | +----------- hour (0 - 23) +------------- min (0 - 59) |
环境：
RedHat Linux
JDK1.6
功能说明：
每天早上2点钟执行一次java程序。
操作步骤：
1、首先，将java程序打包成为jar包，包名为unarchivegzipandinsertintodb2_0_1.jar,注意要设置该jar包的MANIFEST.MF的Main-Class的类，
将jar包复制到/usr/local/目录下，同时将该jar包所依赖的jar包也复制到/usr/local/目录下，如test.jar；
2、在/usr/local/目录下创建shell脚本，脚本名称auto.sh,脚本内容为:
#!/bin/bash
cd /usr/local/
#!/bin/sh
cd `dirname $0`
/usr/local/jdk1.6.0_25/bin/java -Xms256M -Xmx1024M -cp /usr/local/jdk1.6.0_25/lib/tools.jar:/usr/local/jdk1.6.0_25/lib/dt.jar:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2/../lib/activation.jar:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2/../lib/advancedPersistentLookupLib-1.0.jar:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2/../lib/systemRoutines.jar:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2/../lib/test.jar::.:/data/appLog/UnArchiveGzipAndInsertIntoDB2_0.1/UnArchiveGzipAndInsertIntoDB2/unarchivegzipandinsertintodb2_0_1.jar: test.unarchivegzipandinsertintodb2_0_1.UnArchiveGzipAndInsertIntoDB2 --context=Default "$@"
说明：
/usr/java/jdk1.6/是java安装路径
java命令后面必须要加入-cp参数，cron在执行时不加载系统环境变量，如果不加这个参数，程序不会正常执行，
即使命令行可以正确执行，但在cron调用时也会出现问题。
3、使用crontab命令，输入如下内容：
00 02 * * * /usr/local/unarchivegzipandinsertintodb2_0_1.sh
说明：
每天早上两点钟执行/usr/local/unarchivegzipandinsertintodb2_0_1.sh脚本，crontab的语法格式表达的含义可以参考相关手册。
最近经常碰到关于crontab不能执行的，初步总结了有以下几个原因：
第一，脚本的原因：大多数情况下，我们要相信科学，相信计算机，不是有鬼，就是我们的脚本的问题，这种问题导致crontab不能执行的概率占到 70%以上。因为程序执行到某一步导致crontab终止执行，我就碰到一次在迁移代码的时候将数据库连错了。导致无法访问而死在那里了。
第二，执行环境问题，当我们碰到第一情况下，一般都可以通过手动执行程序将问题扼杀在摇篮里，一般情况下高手是不应该犯第一种错误的。问题是当我们 手动执行成功而crontab不能执行的时候，笔者碰到一次就是执行环境的问题，例如相关路径的设置问题。解决方案：在代码最前面执行 source /home/user/.bash_profile
第三，系统时间不正确。这种问题最好理解，也是比较常见和隐蔽的问题，解决方案：date -s ********
第四，就是我们的脚本是否有可执行权限。必须保证执行脚本的用户有执行改文件的权限。
第五，crontab 守护进程死掉了。这种情况是极少发生的，但也不排除，当我们实在是找不到其他原因的时候可以用。解决方案：重启该进程。
另外，介绍大家一个关于如何查看crontab最修修改时间的方法：
进入目录/var/spool/cron/里面会有N个用户名为文件名的文件，只要建立过crontab的用户在这里都会有以该用户名为文件名的文件，该文件的最后修改时间就是该用户的的crontab的最后修改时间。