• 博客访问: 467513
  • 博文数量: 337
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-01 20:58
个人简介

暂无介绍

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(337)

文章存档

2011年(1)

2010年(22)

2009年(35)

2008年(41)

2007年(143)

2006年(39)

2005年(56)

我的朋友
微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

一起诡异的CRONTAB事件 2010-09-11 20:54:37

分类: IT综合技术



某个业务因为系统事件跟标准时间相差太大,挂了,排查下来发现凶手是因为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秒,看看将要执行的命令是不是你期望的命令,有时候打错一个字母、多或者少打一个字母都是有可能的,但也许这一个字母就可能导致一起事故。


宁停三分,不抢一秒![@more@]
阅读(2234) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册