|
* * * * * 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的最后修改時間。