Linux crontab定时器设置（定期执行java程序)(转)

Posted 2020-10-09 莫为

Crontab 语法

Crontab语法一个crontab文件用五个段来定义：天，日期和时间，和一个要定期执行的命令代码。

*    *  *  *   *  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 "[email protected]" 
    
     说明：
     /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的最后修改时间。