crontab定时任务被清空的故障原因定位及复盘过程

0    94    1

Tags:

👉 本文共约1857个字,系统预计阅读时间或需7分钟。

一、问题描述及事件经过

大年二十九,接到运维值班同事反馈的一个问题:

某生产服务器上的1月17号下午1点左右业务部门运维人员通过堡垒机登录时查看crontab -l定时任务是在的

但是1/18号早上业务部门另外一名运维人员,通过堡垒机登录时查看crontab -l却发现全空了

crontab定时任务被清空的故障原因定位及复盘过程

当时已经通过1月17号的堡垒机上的运维日志恢复了crontab定时任务,业务已经修复

但要回溯一下crontab -l被清空的根因, 业务部门一度怀疑17-18号这期间是不是有人绕过堡垒机登录过这台服务器,做过啥运维操作导致crontab定时任务被清空

二、问题原因分析过程

当运维值班同事的这个问题反馈过来后,开始着手分析

1、先排查SSH ACL访问控制,白名单配置文件中没有堡垒机以外的IP地址

为了证明不存在堡垒机绕过的情况,我这里直接GrayLog日志服务器查询了一下这台服务器这个时间区间的SSH登录日志 除了堡垒机IP没有其他IP有登录过服务器的SSH

crontab定时任务被清空的故障原因定位及复盘过程

再说了,即使有绕过堡垒机登录的情况,GrayLog也会发送相应的堡垒机绕过告警到运维群里

所以不要怀疑自己这个SSH防堡垒机绕过的安全加固机制,要对自己有信心

2、这时查看堡垒机的1/18号最早的运维日志记录

crontab定时任务被清空的故障原因定位及复盘过程

只发现crontab -l 多了一个空格,也只发现这样一个异常

我尝试在Linux虚拟机上做了测试,crontab - l 多了一个空格,这时会话会卡住

这时Ctrl+C直接退出,然后再crontab -l 查看crontab定时任务还是在的

crontab定时任务被清空的故障原因定位及复盘过程

3、所以很诡异,问题陷入僵局

根据上面的测试论证,看来多一个空格也不至于说会把crontab定时任务清空哈 所以问题卡住

4、借助搜索引擎

这时不要禁锢在思维定势里,借助搜索引擎尝试找找有没有其他可能性

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!
crontab定时任务被清空的故障原因定位及复盘过程后续精彩内容已被小麦苗无情隐藏,请输入验证码解锁本站所有文章
验证码:
请关注本站微信公众号,回复“小麦苗博客”,获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部