crontab 被内容清空

转载：http://zhang41082.itpub.net/post/7167/505262

某个业务因为系统事件跟标准时间相差太大，挂了，排查下来发现凶手是因为CRONTAB中设置的定时任务消失导致，而这个定时任务干的活就是定期进行时间同步。开始怀疑是谁手工把定时任务干掉了，但是排查日志发现现象很诡异，询问所有有机器访问权限的人，没有人修改过这个咚咚。

/var/log/cron中的CRONTAB运行日志如下
Sep 7 12:22:18 machine1 crontab[14762]: (root) REPLACE (root)
Sep 7 12:23:01 machine1 crond[5696]: (root) RELOAD (cron/root)

/var/log/message中的系统日志如下：
Sep 7 12:22:18 machine1 su(pam_unix)[14626]: session closed for user root

唯一的线索就这么多了，从日志上看很可能是关闭ROOT用户的会话的同时，CRONTAB脚本进行了变更，那么什么情况下才会发生这样的问题呢？经过不停的模拟各种场景，终于找到了。首先开一个窗口，直接运行CRONTAB命令，然后直接把这个窗口关掉，这个时候后台的日志中就会记录关闭了ROOT用户的会话，但同时因为ROOT用户在执行CRONTAB命令，所以CRONTAB命令也被关闭，但见鬼的就是关闭CRONTAB命令的同时，会把CRONTAB里所有已经配置好的任务给清空。

那么很可能的场景如下：因为VPN访问生产系统，所以网络不那么好，所以有时敲下字母没反应的时候，就因为可能断掉了，然后就敲回车去进行重新连接，但很可能你已经敲下去的部分命令就这么被发送到服务器上被执行。所以CRONTAB被不带任何参数的去执行了，而正好网络中断或者关闭了客户端，那么就发生了上面出现的诡异现象。

一个好的习惯是，当网络不那么好的时候，一定要有耐心，敲回车之前多等3秒，甚至5秒，看看将要执行的命令是不是你期望的命令，有时候打错一个字母、多或者少打一个字母都是有可能的，但也许这一个字母就可能导致一起事故。


宁停三分，不抢一秒！