crontab坑

一、伤不起的DOS格式文件

全服LOGDB要增加一个crontab条目，需要定时运行一个脚本。在分发完脚本之后，打算用crontab File命令加载File中的crontab条目。于是在本地创建了File文件，使用crontab -l将条目复制到本地的File文件中，然后再添加上新的条目。保存完文件后，将文件上传到运维机，并用ijobs进行分发，最后使用crontab File命令进行重新加载。下面来见证悲剧的时刻：脚本没有执行。

首先先去看看crontab，条目存在，说明在加载File文件中条目是没有问题的，然而这

些脚本都没有定时运行。于是查看系统日志/var/log/messages文件，发现了如下的情况：

^M，这个是dos格式的换行符。悲催的，难道使用了本地加载文件才出现如下状况吗？于是使用cat –A命令来查看隐藏的字符串，果然。。。。。。

结尾都有^M的符号在。在使用dos2unix命令后对该文本格式进行转化后，^M字符消失，然后使用crontab File重新加载后，crontab条目中的脚本正常运行。

二、死活不执行的脚本

不知道各位亲有没有遇到过如下情况：在当前shell环境下运行shell脚本是正常的，但是一旦写到crontab中，就死活不执行。参照了网上的指示，把各个命令和文件都使用了绝对路径，但是那个脚本还是不执行。查看/var/log/messages日志后发现，该脚本已经执行了的，但是却没有得出任何结果，说明脚本在执行过程中出现了问题。在确认脚本无误后，就把重点放到了crontab上，到底是什么原因导致脚本在crontab中出现问题呢？叮~~~相信有经验的童鞋已经猜到了，是环境变量。

脚本在当前shell执行的时候，使用命令时会去查找环境变量，管路径的环境变量正是PATH，echo $PATH就可以查看。而crontab中使用的环境变量却不是当前shell的PATH环境变量，所以在查找命令的时候不是按照当前shell的PATH变量中的路径去查找，所以导致脚本中的命令没有正常执行。可以将当前shell的PATH变量使用export导入的脚本中。

三、没有加载的crontab

不知道各位童鞋有没有遇到这种情况：整个crontab中的脚本都没有运行，已经排除上述的两种情况后还是存在问题，那么恭喜你，中奖了。去看看/var/log/messages的日志吧，看看有没有找到如下的提示：

no passwd entry.

找到的话，果断找SA重启crontab吧，crontab加载crontab文件出现了问题。在重启crond进程后问题得到解决。在每次修改crontab中的内容后，系统会在下一分钟初加载最新修改后的crontab，加载完之后，/var/log/messages中会有一条RELOAD的日志：

reload.

所以不必心急crontab中的脚本没有立即执行，可能还没有加载上最新crontab的缘故。

四、爬坑建议

1. 在不确认的情况下，去查看/var/log/messages日志，很多问题都会记录在日志中

2. 在crontab加载文件的时候，务必确保加载的文件是UNIX格式，而非DOS格式，使用dos2unix命令进行转换，使用cat –A命令查看文件。

3. crontab中的脚本和命令务必使用绝对路径

4. crontab中的环境变量和当前shell的环境变量不同，为保证脚本顺利运行，可将当前shell的环境变量PATH导入脚本中

5. 出现no passwd entry日志记录，可联系SA进行共同解决问题

6. crontab修改后重新加载时，会在日志中记录RELOAD，由此可确认修改后的crontab内容是否正常加载。