Linux中crontab的坑爹環境變量問題

手動在CentOS中執行sh腳本，調用java程序，一切正常；

將該sh加入crontab中定時調度以後，掛了，徹底沒有執行到的感受啊！！！

查看crontab執行日誌：

cat /var/log/cron

有執行記錄，擦擦擦~~~

難道用crontab調用執行會報錯，打印日誌先：

crontab -e

40 10 * * * /home/job.sh 2>>/home/log

再調度一次，查看日誌：

cat /home/log

還真報錯了：

Exception in thread "main" java.lang.ClassFormatError: SystemInfo (unrecognized class file version)

...

TMD，不能識別的java版本，大膽的懷疑crontab用的環境變量是他自個的：

cat /etc/crontab

果真，crontab本身有一個PATH變量，修改之：

vim /etc/crontab

從新用crontab調用程序，報錯依舊，重啓之：

service crond restart

再調用，繼續報錯，難道crontab的PATH是個擺設！

google之，baidu之，原來這是個坑人無數的問題，如下是查到的一些有用的資料：

http://xiachaofeng.iteye.com/blog/1405184

今天碰見一個問題，crontab的定時任務不能自動執行，可是手動執行腳本一直能成功。查到最後，發現是腳本里用了系統的環境變量。下面開始解釋：

0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh

2） 每條 JOB 執行完畢以後，系統會自動將輸出發送郵件給當前系統用戶。日積月累，很是的多，甚至會撐爆整個系統。因此每條 JOB 命令後面進行重定向處理是很是必要的： >/dev/null 2>&1 。前提是對 Job 中的命令須要正常輸出已經做了必定的處理, 好比追加到某個特定日誌文件。
3）當crontab忽然失效時，能夠嘗試/etc/init.d/crond restart解決問題。或者查看日誌看某個job有沒有執行/報錯tail -f /var/log/cron。
4）千萬別亂運行crontab -r。它從Crontab目錄（/var/spool/cron）中刪除用戶的Crontab文件。刪除了該用戶的全部crontab都沒了。
5）在crontab中%是有特殊含義的，表示換行的意思。若是要用的話必須進行轉義\%，如常常用的date ‘+%Y%m%d’在crontab裏是不會執行的，應該換成date ‘+\%Y\%m\%d’`。

3.crontab中的輸出配置

crontab中常常配置運行腳本輸出爲：>/dev/null 2>&1，來避免crontab運行中有內容輸出。

shell命令的結果能夠經過‘> ’的形式來定義輸出

/dev/null 表明空設備文件　　

> 表明重定向到哪裏，例如：echo "123" > /home/123.txt　

1 表示stdout標準輸出，系統默認值是1，因此">/dev/null"等同於"1>/dev/null"

2 表示stderr標準錯誤

　 & 表示等同於的意思，2>&1，表示2的輸出重定向等同於1　

那麼重定向輸出語句的含義：

1>/dev/null 首先表示標準輸出重定向到空設備文件，也就是不輸出任何信息到終端，不顯示任何信息。

2>&1 表示標準錯誤輸出重定向等同於標準輸出，由於以前標準輸出已經重定向到了空設備文件，因此標準錯誤輸出也重定向到空設備文件。