今天老張看到後臺很多質量異常的數據
勒令我去解決
東西很簡單，就是im的一個自維護腳本
測試
kill 進程
手動執行腳本ok kill的進程啓動
首先不經大腦的懷疑crontab有問題
測試：
測試一個簡單的腳本，發現crontab沒有問題
之後就是各種折騰 最後無果
求助張總，張總大牛也
經驗十足的給小趙做了演示
加入腳本執行過程的信息收集（經驗啊，學習到了。自己還是太low）
*/1 * * * * /bin/bash /data/scripts/proxy_auto_sh/auto_restart_proxy.sh > ~/debug 2>&1
執行之後查看debug文件內容
error while loading shared libraries: libmysqlclient.so.15: cannot open shared object file: No such file or directory
error while loading shared libraries: libmysqlclient.so.15: cannot open shared object file: No such file or directory
明白了
腳本是一般用戶的腳本，計劃任務也是一般用戶的計劃任務
需要講講我們的im程序了，他是依賴我們開發的動態鏈接庫
我們部署的時候是這個動態鏈接庫的路徑，加入用戶的.bash_profile文件裏面
手動執行的時候，該用戶已經帶入了這個值，但是這種非系統的環境變量在crontab是不識別的，在腳本加入source解決
問題雖小，但是加深了對crontab的理解以及排查問題的思路
總結：
crontab與環境變量以及需要注意的問題（來自於網絡）
不要假定cron知道所需要的特殊環境，它其實並不知道。所以你要保證在shelll腳本中提供所有必要的路徑和環境變量，除了一些自動設置的全局變量
需要注意：
1）腳本中涉及文件路徑時寫全局路徑
2）腳本執行要用到java或其他環境變量時，通過source命令引入環境變量
其他需要注意的是：
1）新創建的cron job，不會馬上執行，至少要過2分鐘才執行。如果重啓cron則馬上執行。
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’`。