今天老张看到后台很多质量异常的数据
勒令我去解决
东西很简单，就是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’`。